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1.5.7.13, Secure Fax Contract Reject 

Secare Fax Contract Reject Request 

MIA Part: 

5 4-byte BIA Identification 

4-byte sequence number 
encryptedfDUKPTkey) Siometric~PlC block: 

30G~byte authorization biometric 

4-12 digit PIC 

10 56-bit response key 

fax tracking number 
MAC 

Terminal Part: (not used) 

55 Secare Fax Contract Reject Response 

encrypted&espome key): 

private code 
status code (ok, invalid individual) 
MAC 

20 

The DPC uses the biornerric-PIC to identify the individual making 
the Contract Reject request. The DPC finds the EDD Recipient record keyed 
by the request's fax tracking number and the individual's biometric 
Identification, if the record cannot be found then the request fails with an 
25 "invalid recipient" status. Otherwise, the DPC updates the Recipient record's 

contract status field to "rejected" and generates a Status Notice to the fax's 
sender (see Fax Data, above). 

1.5.7.14. Secure Fax Organization Change 

30 

Secure Fax Organization Change (Secure Fax message) 
sender name, company, title, and fax number 
list of organizational changes 

35 Organization changes are submitted to the DPC via a secure fas 

message. A customer support engineer enters ibe changes requested in the fax 
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message, Venning that the individual submitting the request is allowed to 
register individuals for that particular company. Since the fax is a secure fax, 
the sender's identity has already been ascertained, as has his title. 

1-5.7,15. Electronic Document Submit 

Electronic Document Submit Request 

BIA Part: 

4-byte BIA Identification 
4-byte sequence number 
encrypiedfDUKPTkeyJ Biomemc-PIC block: 

300-byte authorization biometric 

4-12 digit PIC 

56-bit response key 

56-bit message key 
recipient list 
MAC 

Terminal Part: (not used) 

Electronic Document Submit Response 
encrypiedfrespome key): 
private code text 
tracking number 

status code (ok, invalid recipient) 
MAC 

When the DPC receives an Electronic Document Submit request, it 
identifies the individual by following the individual identification procedure. ' 

The DPC then creates an EDD Document record and assigns it a 
unique tracking number. The DPC initializes the record's sender identification 
code to be the biometric identification code of the identified individual and the 
message key to be the message key in the request. 

Next, the DPC searches the individual Biometric Database for each 
recipient and creates an EDD Recipient record for each one. Each record is 
initialized with the tracking number, the recipient's biometric identification 
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code, and a delivery status of "incomplete". If any of the recipients cannot be 
found, the DPC replies with an "invalid recipient" status. 

L5.7J6. Electronic Document Data 

Electronic Document Data Request 

SIA Part: (not used) 
Terminal Part: 

tracking number , 

command (either abort or data) 

[optional message ofiset] 

completion indication 

encryptedfmessage key): 
message body 

Electrook Document Data Response 

status {incomplete, ok) 

The Electronic Document Data request allows an individual to send 
the document text (in one or more parts) to the EDD for delivery to the 
rectpient(s). This request does not involve any biometric identification, instead, 
it relies upon the secret message key to securely transmit the document text. 

The request text is assumed to be encrypted by the message key 
stored in the EDD document record and is appended to the document text 
already stored in the record. 

When the EDD receives a packet with the "document complete" 
indicator, it knows that the sender has finished transrnhting the document. The 
EDD now sends an Arrival Notice to all recipients of the document via internet 
electronic mail irrforming them that they have a document waiting. 

The Arrival Notice is as follows; 
Electronic Document Arrival Notice (Internet E-mail message) 
sender name, company, title, and e-mail address 
tracking number 

instructions on how 10 receive the electronic document 
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The EDD also updates the status of the EDD recipient record to 
"notified When ail recipients have either retrieved or rejected the elearonic 
document, the DPC sends a Status Notice via Internet electronic mail to the 
document originator. 

5 

The Status Notice is as follows: 
Electronic Document Status Notice (Internet £~raaii message) 
sender name, company, title, and e-ntaii address 
tracking number 
i0 hst of recipients showing for each 

name, company, title, e-mail address 
delivery date and status 

The DPC finds each individual's company and title information in 
15 the EDD Organization table. 

1.5.7.17. Electronic Document Retrieve 

Electronic Bocument Retrieve Request 
20 £14 Part: 

4-byte BIA Identification 
4-byte sequence number 
GKiypt*d(DUKPTkey) Biometric-PIC Mock: 
300-byte authorization biometric 
25 4-12 digit PIC 

56-bit response key 
tracking number 
MAC 

Terminal Part: (mimed) 

30 



105 



PCI7US96/07185 



Electronic Bocuioeiit Retrieve Response 

encryptedfresponse key): 

private code 

56-bit message key 
status (incomplete, ok, invalid recipient) 
MAC 

emr^ptedfmessage key): 
document text 

The DPC uses the biometric-PIC to identify the individual making 
the electronic document retrieve request by lowing the individual 
identification procedure. 

The DPC next finds the EDD Recipient record keyed by the 
tracking number and the individual's biomemc Identification. 

If the record cannot be found, then the request fells with an "invalid 
recipient" status. Otherwise, the DPC sends the document's message key and 
the document (still encrypted by the message key) to the requester. 

The EDD then updates the status of the EDD recipient record to 
"retrieved". When all recipients have either retrieved or rejected the document, 
the DPC sends a Status Notice via Internet electronic mail to the document 
originator (see Electronic Document Data, above) and then schedules to 
remove the Document and Recipient records (see Secure Fax Retrieve, above) 

L5.748. Electronic Document Reject 

Electronic Document Reject Request 

BIAPart; 

4~bvte BIA Identification 
4-byte sequence number 
mcryptedfDUKPT key) Biomeiric-PfC Mock 

30CH>yte authorization biometric 

4-12 digit PIC 

So-bit response key 
message tracking number 
MAC 

TermimlPart: (not used) 
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Electronic Bocumeuf Reject Response 

mcrypted(respans& key): 

private code 
status code (ok, invalid recipient) 
MAC 

The DPC uses the biometric-PIC to identify the individual making 
the electronic document reject request. The DPC next finds the HDD 
Recipient record keyed by the tracking number and the individual's biometric 
Identification. If the record cannot be found, then the request 63s with as 
"invalid recipient" status. 

The HDD updates the status of the EDD recipient record to 
"rejected" The DPC then follows the same notification and deletion procedure 
as described in Electronic Document Retrieve, above. 

1.5,749. Electronic Doctunest Archive 

Electronic Document Archive Request 
BIA Part: 

4-byte BIA Identification 
4-byte sequence number 
encrypted(DVKPTkey) Biametric-PIC block 

300-byte authorization biometric 

4-12 digit PIC 

56~bk response key 
tracking number 
MAC 

Terminal Part: (not used) 

Electronic Document Archive Response 
encrypted&esponse key): 

private code 
status code (ok, invalid individual) 
MAC 
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The DPC uses the biomerric-PIC to identify the individual making 
the electronic document archive request. The DPC finds the HDD Recipient 
record keyed by the request's tracking number and the fedividuafs biometrk 
Identification . If the record cannot be found and the individual is not the 
seader or one of the recipients, then the request fails with an "invalid 
individual'' status. Otherwise, the DPC copies the Document and Recipient 
records into the EDD archive database. Any subsequent changes to these 
records are also copied to the archived versions, 

1.5.7.20, Electronic Document Archive Retrieve 

Electronic Document Archive Retrieve Request 
BlAPart: 

4-hyte B1A Identification 
4-byte sequence number 
encryptedfDUKPTkey) Biomemc~PIC block: 

30fM>yte authorization biomethc 

4-12 digit PIC 

56~bit response key 
optional title index code, sending fax number, and extension 
tracking number 
MAC 

Terminal Pari; (not used) 

EJectronic Document Archive Retrieve Response 

mcTypted(re$poftse key); 

private code 
status code (ok, invalid individual) 
MAC 

The DPC can receive an Electronic Document Archive Retrieve 
request from either a Secure Fax Terminal or a Certified Email Terminal. The 
DPC uses the individual identification procedure to determine the individual 
submitting the archive retrieve request. The individual must be either the 
sender or one of the recipients or else the DPC denies the request by setting 
the status code to "invalid individual". However, if the archived document was 
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a fax sent using a corporate title, the DPC allows additional mdividuals whose 
titles are higher in the corporate hierarchy to retrieve the archived document as 
well. 

The HDD maintains an archive database, indexed by the document's 
5 original tracking number, stored on off-line media such as CD- ROMs and 

tape that can take considerable time to search for the archived document. As a 
result, the DPC does not return the archived document irnmediateSy, but 
instead informs the requesting individual that the DPC has begun the search. At 
a later date when the DPC finishes the search, it notifies the requester that the 
10 archived document is ready to be retrieved through the standard document 

arrival notification mechanisms - either via fax or email depending on the 
format of the original document. 

The DPC creates an HDD archive request record to store 
information about the requester so that when the search completes, the DPC 
15 remembers to whom to send the document, 

1.5.7,21, Electronic Signature 

Electronic Signature Request 
20 BlAPart; 

4~byte BIA Identification 
4-byte sequence number 
encryptedmVKPTkey) Biometrie~PlC Mock: 
300-byte authorization biometric 
25 4-12 digit PIC 

56-bit response key 
document name 
document MD5 calculation 
MAC 

30 TermimiPart: (hoi used) 

Electronic Signature Response 

encryptedfrespanse key): 
private code text 
35 signature string 

MAC 
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To process the electrode signature request, the DPC first performs 
a biometric identification using the biometric-PIC. Then, the DPC creates an 
ESD record, assigns it a unique signature identification code, and sets the 
record's signature field to the electronic signature in the request. The DPC 
then returns a signature string that can be submitted for later verification: 

"<Dr, Bunsen Honeydew> <Explosions in the Laboratory> 5/17/95 13;00 
PST 950517000102" 

1.5.7.22. Electronic Signature Verify 

Electronic Signature Verification Request 
BIA Part: 

4-byte BIA Identification 
4-byte sequence number 
encr)pted{DiMPTkey) Biometric-PIC block: 

300-byte authorization biometric 

4-12 digit PIC 

56-bit response key 
signature siring 
MAC 

Terminal Part: (not used) 

Electronic Signature Verification Response 
ettctyptedfresponse key): 
private code text 
signature string 
status (verified, failed) 
MAC 

The DPC performs a biometric identificatiori, extracts the signature 
tracking code from the signature string, retrieves the indicated ESD record, 
and verifies that it matches the signature string. The DPC returns the private 
code and the outcome of the signature comparison. 
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1.5.7.23 Network Credential 

Network Credential Request 

B1A Part: 

4-byte BIA Identificalian 
4~byte sequence number 
mcrypied0W£PTkey) Biomeiric-PIC block: 

300-byte authorization bioraetric 

4-12 digit PIC 

56-bit response key 
account index 
bank code 
bank hostname 

tenninaLport and baokport (TCP/EP addresses) 
MAC 

Network Credential Response 

emrypied(respon$e key): 

private code 
signed0PC's private key): 

credential(time, aect, terminal, port, bankport) 
bank's public key 
status code (ok, failed) 
MAC 

The DPC identifies the individual using the request's biometric-PIC 
and retrieves the individual's asset account stored at the specified index. If the 
account index is the emergency account, then the network credential response 
status code is set to "failed" and no credential is generated. 

The DPC constructs the credential using the current time, the 
retrieved asset account, and the TCP/IP addresses of the terminal and the bank 
The DPC ihen uses public key encryption to sign the credential with its private 
key. 

The response also includes the bank's public key, which the DPC 
retrieves from the Remote Merchant Database. 
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1.5.8. Customer Support and System Administration Messages 

The DPC handles additional message types classified as iiuemai 
messages. The DPC generally does not accept these messages from non-DPC 
systems. The messages are database vendor specific. However, the internal 
network uses DE$~encrypted packets to provide additional security. 

The Customer Service and System Administration tasks are 
implemented using the database vendor's query language and application 
development tools. 

1.S.8.L Customer Service tasks: 

* B3D: find, activate, deactivate, remove, correct records. 

* AID: add or remove authorized mdividuals. 

* ADD: find, add, remove, cornea records. 

* VAD; fiad, activate deactivate, remove, correct records. 

* HMD: find, add, remove, correct records. 

* PFD: add, remove, correct records, 

1.5.8.2. System Admiaistration tasks: 

* Run prior fraud checks. 

* Modify the Valid Site List. 

« Summarize log information (warnings, errors, etc. ). 

* Modify the PIC Group List. 

* Performance monitoring, 

* Run backups, 

* Crash recovery procedures, 

* Time synchronization for the DPC sites. 

* Change the primary registration site. 

* Change the secret DES encryption key, 

» Clean up old document tracking numbers. 

* Generate a list of BIA hardware identification code, MAC encryption 
key, and DUKPT Base Key triples. Store oh an encrypted floppy 
for the Key Loading Device. 
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1.5.9. Firewall Machine 
1,5.9.1. Purpose 

The FW Machines provide a first line of defense against network 
viruses and computer hackers. All communication links into or out of the DPC 
site first pass through a secure FW Machine. 

1.19.2. Usage 

The FW Machine, an intemet-iocakset router, only iiandies 
messages destined for the GM Machines, 

BIA-equipped terminals send packets to a single DPC site via 
modem, X.25, or other communication medium. The DPC relies on a third 
party to supply the modem banks required to handle the volume of calls and 
feed the data onto the DPC backbone. 

For DPC to DPC communication, primarily for distributed 
transactions and sequence number updates, the FW Machines send out 
double-length DBS encrypted packets. The DPC LAN component handles the 
encryption and decryption; the FWs do not have the ability to decrypt the 
packets. 

1.5.9.3, Security 

A properly configured network sniffer acts as an intruder detector 
as backup for the FW. If an anomalous message is detected, the mtruding 
messages are recorded in their entirety, an operator is alerted, and the FW is 
physically shut down by the smffer. 

The FW disallows any transmissions from the internal network to 
the rest of the Internet. 

1.5.9.4. Message Bandwidth 

A transaction authorization request requires about 400 bytes and 
registration packets require about 2KB. To handle 1000 transaction 
authorizations per second and 1 registration packet per second, the FW 
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Machines are able to process about 400 KB per second (ail known in the 
industry) . 

Each DPC site requires m aggregate bandwidth of nearly three T1 
connections to the third party modem bank and the other DPC sites, 

1.5,10, Gateway Machine 

1.5.10.1. Purpose 

The GM Machine (GM), through the FW Machines, link the 
outside world (BIA-equipped terminals and other DPCs) to the interna] 
components of the DPC. The DPC has muitipie GMs, typically two 

1.5.10.2. Usage 

The GM supervises the processing of each BIA request, 
communicates with the various DPC components as necessary, arid sends the 
encrypted results of the request back to the sender. The software performing 
this task is called the Message Processing Module. 

The GM logs all requests it receives and any warnings from 
components it communicates with. For example, the GM logs any emergency 
account accesses, sequence number gaps, and invalid packets. 

Processing a request may require the GM to inform GMs at all 
other DPCs of a change in the DPC databases. When this happens, the GM 
runs a distributed transaction to update the remote databases. 

Distributed transactions fall into two categories: synchronous and 
asynchronous. Synchronous distributed transactions require the GM to wait for 
the distributed transaction to commit before continuing to process the packet. 
Asynchronous distributed transactions do not require the GM to wait for the 
commit, and allow it to finish processing the request regardless of whether the 
distributed transaction commits or not. Asynchronous distributed transactions 
are only used to update data for which database consistency is not an absolute 
requirement: sequence numbers and biometric checksum recordings may be 
performed asynchronously, whereas creating database records, such as 
Individual Biomeiric records, may not. 
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When executing a synchronous distributed transaction, the 
requesting GM only considers the entire transaction successful if all sites can 
successfully commit the transaction locally. Otherwise, the GMs back out the 
changes locally and reject the request due to a transaction erf or. 

The Est of valid DPC sites is normally ail of the sites. In the case of 
an extreme site failure, however, a system aatrumstrator may manually remove 
that site from the valid site list. The most likely cause of distributed transaction 
failures, however, are temporary network failures that are unrelated to any 
DPC equipment. Requests that require a synchronous distributed transaction 
cannot be performed until network connectivity is restored or the site is 
removed from the valid site list. Before a site can be added back to the valid 
she list, the system administrator brings the site's databases up to date with 
those of a currently active site. 

1.3.16.3. Software Components 

Each GM runs the following software components locally for 
performance reasons: 



Message Authentication Code Module 

Message Decrypt Module 

Individual Biometric Database Machine List 

1.5.10.4. Message Bandwidth 

The message bandwidth required by the GMs is similar to that 
required by the FW Machines, A FDD! network interface provides 1 00 MBits 
per second and easily covers any bandwidth requirements. 

1.5.11 DPC LAN 

1.5.11.1 Purpose 

The DPC Local Area Network (LAN) links the machines of the 
DPC sites together using a fiber optic token ring. The fiber optic token ring 
provides both high bandwidth and good physical security. 
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1&.U.2 Security 



The network interfaces used by the machines on the DPC LAN 
include encryption hardware to make tapping or intercepting packets useless 
without the encryption key. The encryption key is the same for all rmchmes on 
the LAN and is stored in the encryption hardwire. 

A properly configured network sniffer acts as an intruder detector 
as backup for the FW. If an anomalou s message is detected, the intruding 
messages are recorded in their entirety, an operator is alerted, and the FW is 
physically shut down by the sniffer. 

1.5,12 Message Processing Module 
L5.12.1 Purpose 

The Message Processing Module (MPM) handles the processing for 
a request packet. It communicates with other components of the DPC as 
necessary to perform its tasks. The presence of an MPM on a machine brands 
it as a GM. 

L542.2 Usage 

The MPM maintains a request context for each request it is 
currently processing. The request context includes the information necessary to 
maintain the network connection to the terminal making the request, the BIA 
device information, the response key, and the response packet. 

1,5.13, Message Authentication Code ModuJe 

1.5.J3J. Purpose 

The Message Authentication Code Module's (MACM) tasks are to 
validate the Message Authentication Code on inbound packets and to add a 
Message Authentication Code to outbound packets. 
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1,5.13.2, Usage 

The MACM maintains an in-memory hash table of 1 12— bit MAC 
encryption keys keyed by BIA hardware identification code. 
5 When the MACM receives a request from the GM to validate a 

packet's MAC, it first looks up the packet's hardware identification code in the 
hash table. If no entry exists, then the MACM replies to the GM with an 
"invalid hardware identification code" error. 

Otherwise, the MACM performs a MAC check on the BIA 
10 message part of the packet using the 1 1 2-bit MAC encryption key. If the 

MAC check fails, then the MACM replies to the GM with an "invalid M*C" 
error. Otherwise, the MACM replies with a "valid MAC" message. 

If the packet contains a merchant code, the MACM also checks the 
merchant code against the owner identification code in the hash table. If the 
i5 codes don't match, then the MACM replies with an "invalid owner" error. 

When the MACM receives a request from the GM to generate a 
MAC for a packet, it iooks up the MAC encryption key using the packet's 
hardware identification code. With the MAC encryption key, the MACM 
generates a MAC and adds it to the packet. If the MACM cannot find the 
20 hardware identification code in its hash table, it replies with an invalid 

hardware identification code error instead. 

L5.1&& Database Schema 

25 The MACM hash table entry contains: 

MACM Entry: 

hardwareld ~ wt4 
ownerld = tnt4 
mcEncrypttonKey ~ mtl6 

30 

The table is hashed by hardware identification code. 
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L5.13.4. Database Size 

Assuming 5 million BIA-equipped devices m service, the hash table 
requires about 120 MB of storage. For performance reasons, this hash table is 
5 cached completely in memory. 

1.5.13.5. Dependencies 

The MACM only contains records referencing active BIA hardware 
10 identification codes and active apparatus owners. Whenever an apparatus or 

apparatus owner is suspended or deleted from the system, the MACM removes 
any entries that reference the identification code. When an apparatus is 
activated, the MACM then adds an entry for it. 

The MACM also caches the MAC encryption key from the Valid 
15 Apparatus Database. Since the system does not allow the encryption key of an 

BIA to be changed s the MACM does not need to worry about receiving 
encryption key updates. 

1.5.14. Message Decrypt Module 

20 

1.5.14.1. Purpose 

The Message Decrypt Module's (MDM) task is to reconstruct the 
DUKPT transaction key and with it decrypt the biometric- PIC block of the 
25 packet. It maintains a list of the DUKPT Base Keys that are required to 

generate the transaction key. 

1.5.14.2. Usage 

30 The MDM constructs the DUKPT transaction key using the 

packet's sequence number as the DUKPT transaction counter, the upper 22 
bits of the BIA. hardware identification code as the DUKPT tamper resistant 
security module <or "TRSM") Identification, and the low 10 bits of the BIA 
hardware identification code as the DUKPT Key Set Identification. 

35 The DUKPT standard specifies how the transaction key is 

generated. The Key Set Identification is used to took up a Base Key from the 
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Base Key List. The Base Key is used to transform the TRSM Identification 
into the initial key via a DES encrypt/decrypt/encrypt cycle. The transaction 
counter is then applied to the initial key as a series of DES 
encrypt/decrypt/encrypt cycies to generate the transaction key. 

For additional security, two Base Key Lists are maintained, one for 
iow security BIA devices and one for high security devices. The MDM chooses 
which Base Key List to use depending on the security level of the device. 

1.5. 14.3. Database Schema 

The MDM Base Key List entry contains: 
MDM Entry; 

baseKey » im!6 

The Base Key List is indexed by Key Set Identification. 
LS.14.4. Database Size 

The MDM maintains an te-memory list of the DUKPT Base Keys. 
Each key requires 1 12-bits. The MDM maintains two sets of 1024 keys 
requiring 32 KB total. 

1.5.14.5. Dependencies 

The MDM has no direct dependencies on arty other DPC 
component. 

1.5.15. PIC Group List 

1.5.15.1. Purpose 

The PIC Group List <PGL), k conjunction with the individual 
Biometric Database Machine List, deines the configuration of the JBD 
machines. The PGL stores a list of the PIC groups in the system which is used 
to simplify the management of the PICs. A PIC group is a set of consecutive 
PIC codes, A PGL exists on each GM Machine (CM). 
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1.5.15.2. Usage 

The PGL, when given a PIC code, searches through its list of PIC 
groups for the group containing the PIC code. The PGL maintains the list of 
groups in order and uses a binary search to quickly find the correct group. 

The initial configuration for the PGL is one giant PIC group 
containing ail possible PICs, After a threshold number of PICs are assigned, 
the giant PIC group is split in two. Thereafter, this process is applied to all 
succeeding PIC groups. 

When a PIC group splits, the PGL assigns a new main and backup 
3BD machine based on available storage on a first-come-fest serve basis. The 
PGL coordinates with the IBD machines to first copy the a&cted records from 
the old mam and backup machines to the new ones, update the ML record, 
and last remove the old main and backup copies. Splitting a PIC group is an 
involved task. The PGL batches split requests to be run when the DPC is 
lightly loaded, for instance, at night. 

The system administrator may also change the main and backup 
IBD machines for a given PIC group if the machines' free storage falls below a 
level required for handling the expected amount of new registrations. 

1.5.15.3. Data base Schema 

The schema for the PIC Group records are: 
PICGroop: 

lowPin = intS 
highPin « intS 
used = irM 

Each PIC group is identified by a unique identifier. For convenience 
the PIC group identification code is the lowPin code for the group, however 
the system does not otherwise rely upon this fact. 

The PGL is keyed by the lowPin field. 
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1.5.15.4, Database Size 

The PGL is expected to contain about 3000 groups (each PIC 
group contains about 1000 active PICs, but may spaa millions of actual PICs). 
5 *n« entire PGL requires about 72 KB of storage and is cached completely in 

memory. 

1.5.15.5. Dependencies 

i0 Wkea PIC groups are added, merged, or split up, the PGL is 

responsible for mforming the ffiD Machine List of the changes and for 
directing the movement of XBD records from one IBD machine to another. 

1.5.16, IndivMaai Biornetrk Database Machine List 

15 

1.5.16.1. Purpose 

The IBD Machine List (IML), in conjunction with the PIC Group 
List, codifies the configuration of the IBD machines. The IML maps a PIC 
20 cc-«ie to the main and backup IBD machines storing JBD records for the PIC. 

The IML is actually keyed by PIC Group (a set of consecutive PIC codes) 
rather than by individual PICs because this greatly reduces the memory 
required to store the list. An IML exists on each GM Machine (GM). 

25 1.5.16.2. Usage 

When a GM processes a request that requires a biometric 
identification, the GM finds the IML record keyed by the biometric's PIC 
group. The GM then knows the main and backup IBD machines to use for the 
30 biometric identification. 
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LS.16 3. Database Schema 

The schema for the IML list entries are: 
MachinePak: 

praGroup ~ intS 

backup = int2 

The IML is keyed by pinGroup, 

1.5.16.4. Database Size 

The IML is expected to contain about 3000 entries (the number of 
PIC Groups). Each MachkePaa* record is 12 bytes requiring about 36 KB of 
storage and is cached completely in memory. 

1.5.16.5. Dependencies 

Any changes in the configuration of the IBD machines are be 
rejected is the ML In addition, the IML uses PIC groups for its keys so 
when the PIC Group List gets modified, the IML are also updated. 

1.547. Sequence Number Module 

1.5.17. L Purpose 

The Sequence Number Module's (SNM) primary function is to 
prevent repky attacks by validating packet sequence numbers. Its secondary 
task is to minimise the effects of a resubmission attack by mforming other 
SNMs in remote DPC sites of sequence number updates and to periodically 
update the sequence numbers in the Valid Apparatus Database, 

The SNM maintains an m-metnory hash table of sequence numbers 
keyed by BIA hardware identification code codes to allow quick validation of 
packet sequence numbers. 
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1,5,17.2. Usage 

When the SNM receives a validate request from the GM for a given 
hardware identification code and sequence number, it looks op the hardware 
identification code in the hash table. If no entry exists, then the SNM replies to 
the GM with an "invalid hardware identification code" error. 

Otherwise, the SNM checks the given sequence number against the 
sequence number stored in the hash table entry . If the sequence number is less 
than or equal to the stored sequence number, the SNM replies with an "invalid 
sequence number" error. Otherwise, the SNM sets the sequence number in the 
hash table entry to the given sequence number and replies with a "valid 
sequence number" message. 

From time to time, the SNM may observe a sequence number gap. 
A sequence number gap occurs when the SNM receives a sequence number 
that is more than one greater than the sequence number stored in the hash table 
entry. In other words, a sequence number was skipped. When the SNM 
discovers a sequence number gap, it replies with a "sequence number gap" 
message to the GM instead of a "valid sequence number" message. The GM 
treats the packet as valid, but it also togs a "sequence number gap" warning. 

Sequence number gaps usually occur when network connectivity is 
lost: packets are dropped or can't be sent until the network is restored to 
working order. However, sequence number gaps occur for fraudulent reasons 
as well: malicious parties could intercept packets preventing them from 
arriving at the DPC or they could even attempt to couaterteit packets (with a 
large sequence number so that it isn't immediately rejected). 

The SNMs secondary function is to kforrn other DPCs of the 
updated sequence numbers. Quickly updating sequence numbers at ail DPC 
sites thwarts resubmission attacks wherein a malicious emit}' monitors packets 
whose destination is for one DPC site and immediately sends a copy to a 
different DPC site in the hope of exploiting the transmission delay of sequence 
number updates from one DPC site to another resulting in both sites accepting 
the packet as valid, when only the first site should accept the packet. 

The SNMs send update messages to each other whenever they 
receive a valid sequence number. If an SNM receives an update message for a 
sequence number that is less than or equal to the sequence numbe- ;urrentiy 
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stored in its hash table, that SNM logs a sequence number resubmission 
warning. All resubmission attacks are detected in this maimer. 

A simpler way to thwart resubmission attacks completely, is to have 
only one SNM validate packets. Under this scheme, there is no update 
transmission delay window to exploit with a resubmission attack Alternately, ■ 
multiple SNMs can be active at the same time provided none of them handle 
sequence number validation for the same BIA-equipped- device, 

1.5.17.3. Sequence Number Maintenance 

When the SNM boots up, it loads the sequence number hash table 
from the sequence numbers for active BIA stored in the VAD. 

Once per day, the SNM downloads the current sequence numbers 
to the local Valid Apparatus Database (VAD). 

The VAD is responsible for sending add-enrry and remove- entry 
messages to the SNMs for any BIA-equipped devices that are activated or 
deactivated to keep the SNM hash table up-to-date. 

1.5.17.4. Database Schema 

The SNM hash table entry contains: 
SNM Entry: 

hardwareld *= int4 
sequenceNumber = int4 

The hash table is keyed by hardwareld. 

IJ.I7.5. Batabase Size 

Assuming about 5 million BIA-equipped devices in service requires 
the hash table to be about 40 MB. 
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1.5.1 7.6. Dependencies 

The SNM depends on the Valid Apparatus Database. When an 
apparatus is suspended or removed from the database, the SNM removes the 
corresponding entry. When an apparatus is activated, the SNM creates an entry 
fork. 

1.5.1 7.7. Message Bandwidth 

The SNMs require a transmission bandwidth of about 8 KB per 
second to handle 1000 update sequence number messages per second. The 
update sequence number messages is buffered and sent out once per second to 
ntuamize the number of actual messages sent 

1.5.18. Apparatus Owner Database 

1.5.18.1. Purpose 

The Apparatus Owner Database (AOD) stores information on 
radMduals or organizations that own one or more BIA-equipped devices. 
This information is used to double check that the BIA devices are used only by 
their rightful owners, to provide asset account information for financial credit 
and debit transactions, and to allow identification of aH BlAs owned by a 
specific individual or organization. 

1.5.18.2. Usage 

Each ADD record includes an asset account to credit or debit tie 
owner when the DPC processes a financial transaction submitted by one of the 
owner's BIA-equtpped devices. For instance, transactions submitted from BIA 
attached to a retaM point of sale terminal involves credits to the asset account, 
while certified electronic mail transmissions results in debits to the asset 
account. 
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1.5.18.3. Database Schema 

The schema for the Apparatus Owner record is: 
ApparatusOwner: 

ownerld - im4 
name » char50 
address - charSO 
ztpCode = char9 
assetAccount = char!6 
status — irttl 
The status field is one of: 
0: suspended 
1: active 

The Apparatus Owner Database is keyed by ownerld. 

1.5.18.4. Database sfee 

The AOD is expected to store about 2 million Apparatus Owner 
records. Each entry is DO bytes requiring about 260 MB of storage. The AOD 
is stored as a hashed iie keyed by owner identification code. A copy of the 
AOD is stored on each GM. 

1.5.18.5. Dependencies 

When entries are removed or suspended from the AOD, any Valid 
Apparatus Database records that reference those apparatus owners are marked 
as suspended. In addition, the MAC Module and the Sequence Number 
Module remove their entries for the suspended apparatuses. 

1.5,19. Valid Apparatus Database 

1.5.19.1. Purpose 

The Valid Apparatus Database (VAD) is a collection of records 
representing all of the BIAs that have been manufactured to date. The VAD 
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record contains the Message Authentication Code encryption key for each 
BIA, as well as an indication of whether an BIA is active, awaiting shipment , 
or marked as destroyed. In order for a message from an BIA to be decrypted, 
the BIA must exist and have an active record in the VAD. 

1.5.19.2. Usage 

When manufactured, each BIA has a unique public identification 
code and a unique MAC encryption key, both of which are entered into the 
VAD record prior to BIA. deployment. 

When an BIA is first constructed, it is given a unique hardware 
identification code. When an BIA is placed in service, its hardware 
identification code is registered with the system. First, the owner or 
responsible party of the BIA is entered into the Apparatus Owner Database 
(AOD). Then, the VAD record is pointed to the AOD record, and the BIA is 
then set active, Requests from that BIA are accepted by the DPC. 

Wihen an BIA is removed from service, it is marked as inactive, and 
the iink to the AOD record is broken. No communications from that BIA are 
accepted. 

Each BIA type and model has a security level assigned to it that 
indicates its level of physical security. When the DPC processes requests from 
that BIA, it uses the BlA's security level to gauge what kind of actions are 
allowed. The DPC also provides the security level to external financial 
transaction authorization services. 

For example, a financial transaction authorization service can 
decide to deny any request for over $300 from iow security BIA, requiring 
individuals to use higher security BIA to authorize such sums. The 
authorization service can also use the security level as a guide on how much to 
charge for the transaction, based on risk. 

The security levels and the actions that they allow are determined 
operationally. Basically, the cost to defraud the system must be higher than the 
potential gain, so the security level is related to the cost to compromise the 
device. 
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1.5.19.3, Database Schema 



The schema for the Valid Apparatus record is: 
Valid Apparatus: 

hardwareld ~ int4 
macEno-yptionKey « intl 6 
ownerld » mtZ 
mffcDate ~ time 
mServiceDare - time 
securityLevel ™ mt2 
status ~ intl 
type ~ intl 
use * intl 



Possible vaiues for the status field are: 
0: suspended 
I : active 
2: destroyed 



Possible vaiues for the type field are (one for each type of terminal): 
0: ATM 
1: BRX 
2:CET 
3:CPT 
4: CST 
5: EST 
6: IPT 
7: IT 
8: OT 
9: PPT 
10: KPT 
11: SFT 
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Possible values for the use field are: 
0: retail 
1: personal 
2: issuer 
3: remote 

The Valid Apparatus Database is keyed by hardware identification 

code, 

1.5.19.4. Database Size 

The VAD handles about 5 miiiion retail, issuer, and remote Valid 
Apparatus entries. Each entry is 51 bytes requiring about 255 MB total. The 
VAD is stored as a hashed file keyed by hardware identification code. A copy 
of the VAD is stored on each GM. 

The number of personal Valid Apparatus entries number in the 
range of 30 miflion requiring another 1.5 GB of storage. 

1.5.19.5. Dependencies 

When a VAD record changes status, the MAC Modules and 
Sequence Number Modules are informed of its change in status. For instance, 
when an apparatus becomes active, the MACP and SNM adds an entry for the 
newly active apparatus. When an apparatus becomes inactive, the MACP and 
SNM remove their entry for the apparatus. 

1.5.20. Individual Biomeiric Database 

l.S.20.1. Purpose 

individual Biometric Database (3BD) records store information on 
individuals, including their primary and secondary biometrics, PIC code, list of 
financial asset accounts, private code, emergency account, address, and phone 
number. The individual may optionally include their SSN and electronic mail 
address. This information is necessary for identifying an individual either by 
biometric or personal information, tor accessing account information, or for 
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providing an address or phone number to remote merchants for additional 
verification, 

LSJWU. Usage 

Individuals are added to the system during the individual enrollment 
process at registered Biometric Registration Terminals located in retail basking 
establishments worldwide, or in local system offices. During enrollment, 
individuals select their personal identification numbers, and add financial asset 
accounts to their biometric and PIC combination. 

Individuals may be removed from the database due to fraudulent 
activity reported by any issuing member. If this occurs, the individual's 
account information is moved from the IBD to the Prior* Fraud Database (PFD) 
by an authorized internal systems representative. The biometric Ids for records 
in the PFD may not be used for records in the IBD. 

The IBD exists on multiple machines, each of wMch is responsible 
for a subset of the JD3D records with a copy of each record stored on two 
different machines, both for redundancy and for load-sharing. The IBD 
Machine List, stored on the GM, maintains which rnachines hoid which HCs. 

l.S.20.3. Database Schema 

The schema for the todividual Biometric record is: 
Individuals iometric: 

primaryBiometric « biometric 
secondfflryBiometric - biometric 
biometricld - im4 
PIC - charlO 
phoneNumber = char!2 
lastName = char24 
SrstName = char24 
middleMtial - char2 
SSN-char9 
privateCode - char40 
address - charSO 
zipCode ~ char9 
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publicKey * char64 
check$un^ = int4£10j 
accountLinks * char30[lOj 
emergencylridex - charl 
emergencyLbik = charl 
privs » char 10 
enroiler = int8 
eraergencyUseCoui« - mt4 
status * intl 

The status field is one of: 
0- suspended 
1: active 
2: priorFraud 

The IBB is keyed by PIC, 

1.5.20.4 Database ladexes 

Each IBD machine has additional indexes on the individual's Social 
Security Number, biometric identification code, last name, first name, and 
phone number to facilitate access to the JBD database, 

1.5,20.5, Database Size 

Each IBD machine has 40 GB of secondary storage provided by 
one or more RAID devices. Each IBD record is 2658 bytes (assuming the 
biometrics are IK apiece) aSowing up to 15 mffiion records per machine. The 
IBD records are stored using a (perhaps clustered} secondary index on the 
PIC. The index is stored in memory and requires no more than 64MB (a 64 
MB index handles about 16 million entries). To store records for 300 million 
individuals, the DPC needs at least 40 IBD machines: 20 IBD rnacames tor 
main storage and another 20 for backup. The number of IBD machines is easily 
scaled up or down depending on the number of registered individuals. 
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1.5.20.6. Dependencies 



The IBD macMues, PIC Group List, and the IBD Machine List 
remain up-to-date in terms of which PICs are on which machine. When a PIC 
group is reconfigured or main and backup machines for PIC groups are 
changed, the IBD machines update their databases and indexes appropriately. 

1.5.2 1. Authorized Individual Database 

L&2LL Purpose 

For each issuer or personal BIA-equipped device, the Authorized 
Individual Database (AID) maintains a list of individuals who are authorized, 
by the owner of the device, to use it. 

The AID exists for two reasons. The first is that it provides 
restricted access to a temunai For example, the issuer Terminal can only be 
used by an authorized bank representative. The second reason for the AID is 
to prevent crimisals from secretly replacing the BIA in a retail point of sale 
terminal with that of a personal BIA from a phone Terminal and thus routing 
ail purchases to a remote merchant account set up by the criminals. 

1.5.21.2, Database Schema 

The schema for the Authorized Individual record is: 
Authorized Individual: 
hardwareld = int4 
biometricld ~ int4 

The hardwareld refers to a record in the Valid Apparatus Database 
and the biometricld refers to a record in the Individual Biometric Database. 
Whenever the DPC needs to check whether an individual is authorized to use a 
personal or issuer BIA device, the DPC checks tor the existence of an 
Authorized Individual record with the correct hardwareld and biometricld. 

Personal BIA devices are identified by a use field set to 1 (personal) 
in the Valid Apparatus Database. Issuer BIA devices are identified by a use 
field set to 2 (issuer) in the Valid Apparatus Database. 
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1.5.21.3. Database Ske 

Assuming each issuer terminal has 10 individuals authorized to use 
it and an each personal device has 2 additional authorized individuals with 
1,000,000 personal devices in the server, the AID stores about: 

10 * 100,000 + 2* 1 ,000,000 - 3,000,000 entries 

The entire database req uires about 24 MB of storage. 

1.5.21.4. Dependencies 

When Authorized Owner Database records or Vafid Apparatus 
Database records are removed, ail Authorized Individual records referencing 
them are removed. 

1-5.22. Prior Fraud Database 

1.5.22.1. Purpose 

The Prior Fraud Database (PFD) is a collection of records 
representing individuals who have defrauded member issuers at some point in 
the past. The PFD also runs background transactions during periods of low 
system activity to weed out individuals in the EBD who have matching records 
mthePED. 

The system does not automatically put individuals in the PFD, 
unless it detects that they are attempting to register again. Placing an individual 
in the PFD is a sensitive policy matter which is outside the scope of this 
document. 

1.5.22.2. Usage 

Before a new IBD record is marked as active, the individual's 
primary and secondary biometrics are checked against each and every 
biometric in the PFD using the same biometric comparison techniques as those 
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used in the individual identification procedure.. If a match is found for the new 
EBD record, the IBD record's status is set to "prior fraud". If the prior fraud 
check was executed as part of a registration, request , the CM logs a 
"registering individual with prior fraud" warning. 

It is assumed that the PFD will remain relatively small. The cost to 
run the PFD is expensive, as it is an involuntary biometrie search, so it is 
important to add only those individuals to the PFD who have imposed a 
significant cost to the system. 

1.5.22.3. Database Schema 

The schema for the Prior Fraud record is: 
Prior Fraud: 

pritnaryBiometric = biometrie 
secondaryBiometric - biometrie 
biometricld « tnt4 
PIC « charlO 
phoneNuinber ~ charI2 
iastName - efaar24 
firstNarae = char24 
middlelnitial =■ char2 
SSN - char9 
privateSignai = ehar40 
address ~ char50 
zipCode - char9 
publicKey ^ ehar64 
checksums - rat4[10] 
accountLinks - char30f 10] 
emergencylndex = char! 
emergencyLink - char 3 
privs^charlO 
enroiier ~ intS 
emergencyUseCount = int4 
status™ intl 
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The status field is one of: 
0: suspended 
i: active 
2: prior fraud 

Hie PFD is keyed by biometric identification code. 

L5.22.4. Database Size 

The PFD record is the same as the IBD record. Fortunately, the 
DPC needs to store a tot less of them so only two dat abase machines are 
required to store the entire database, of which one is the backup. 

1.5.22.5. Dependencies 

The PFD does not have any direct dependencies on any other DPC 
component, 

1.5.23. Issuer Database 

L5.23.L Purpose 

The Issuer Database (ID) stores information on banks and other 
financial institutions that allow their asset accounts to be accessed through the 
system. The issuing institutions are the only entities that can add or remove 
their asset account numbers to a given individual's IBD record. 

1,5.23,2. Usage 

The DPC uses the ID to validate requests from Issuer Terminals by 
searching the ID for a record containing the Issuer Terminal"* issuer code. The 
owner Identification stored in the record must match up with the owner stored 
in the Valid Apparatus Database for the B1A stored in the Issuer Terminal. 
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The schema for the Issuer record is: 
Issuer Record: 

issuerCode « im6 
ownerld ™ int4 
name = charSQ 
phcmeNumber ~ ch&rll 
address <* eharSO 
zipCode *= char9 

The Issuer Database is keyed by issuerCode. 

1.5.23.3. Database Size 

The Issuer Database handles about 100,000 entries, Each entry is 
127 bytes requiring less than 2 MB. A copy of the ID is stored on each GM. 

1.5.23.4. Dependencies 

The Issuer Database does not have any direct dependencies on any 
other DPC component. 

1.5.24. Electronic Document Database 

1.5.24.L Purpose 

The Electronic Document Database (EDD) stores and tracks 
electronic documents such as fax images and electronic mail messages destined 
for specified individuals. It also maintains corporate organizational charts to 
provide the official titles of both sender and receiver. The EDD also archives 
the documents at the sender or receiver's request and provides a neutral, 
third-party verification of contract agreements submitted through the system. 
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1,5.24.2. Usage 

When the DPC receives a fax or other electronic document from an 
individual, it creates an EDD Document record to store the document until it is 
5 picked up by the authorized recipients. 

For fax documents, the recipients are specified by rax number and 
extension. For other electronic documents, the recipients are specified by 
electronic mail address , The DPC looks up an Organization record for each 
recipient by fax number and extension or e-mail address. If the record cannot 
30 be fol >nd 5 then the DPC looks in the Individual Biometric Database but oniy if 

the recipient is specified by e-mail address. For each recipient, the DPC creates 
a Recipient record that references both the Document and the recipient's 
biomeiric Identification specified by the Organization or EBD record if found. 
The DPC allows recipients who are not registered in the system, but it cannot 
15 then ensure delivery or confidentiality for those recipients. 

The EDD is flexible enough to allow fax documents to be sent to an 
individual's e-mail address and e-mail messages sent to a fax machine. 

While no electronic signature is placed on the document by the 
system, the system does guarantee through encryption that the message as 
20 received (and decrypted) by the Certified Email or Secure Fax terrninai was 

sent by the individual. 

Duly authorized officers of the organization can submit secure faxes 
or electronic messages to the DPC to assign title and fax extensions to new 
members, to update a member's title or fax extension, or to remove terrninated 
25 members. 

When an individual is removed from the organization tree, the DPC 
retires the extension number for a period of one year. This retirement period 
allows the individual sufficient time to inform confidants that he can no longer 
receive confidential faxes at that extension and so that the organization cannot 

30 mistakenly activate someone else at the extension who might then otherwise 

receive faxes not intended for him or her. 

The EDD maintains an archive database which contains copies of 
Document and Recipient records when requested by the sender or one of the 
recipients of the document. The archive database is periodically moved onto 

35 CD-ROM. 
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1.5.24.3. Database Schema 

The EDD has three record types: 

Document Record: 

documentNurober = int8 
senderld * int4 
docurnentFax = fax 
docuraeritText « text 
messageKey ~ int8 
status = iatl 

Recipient Record: 

documentNumber - intS 
recipientld = int4 
recipientFaxNumber - char 12 
recipientFaxExtensiori - charS 
reripientEroailAddr - text 
receivedBy - tnt4 
iastModified = time 
delivery-Status = intl 
cootractStatus = intl 

Archive Request Record: 
biometricld - int4 
documemNumber = intS 
requestorFaxNumber = cfaarl2 
requestorFaxExtensiori = charS 
requestorEraatlAddr = text 

Organization Record: 

biometricld = int4 
registeredBy = int4 
company - text 
title = text 
faxNuraber - charl 2 
faxExteitsion - chai S 
emaiiAddr ~ text 
activeDate - time 
privs - mil 
status ~ its i 
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The Document record status field is one of: 
0: incomplete 
I: ok 

The Recipient record delivery status field is one of: 
0: incomplete 
1: notified 
2: rejected 
3: retrieved 
4; retrieved unsecured 
5: busy 

The Recipient record contract status field is one of: 
0: none 
1: accepted 
2: rejected 

The Organisation record status field is one of; 
0: active 
1; suspended 

The Organization record privs** field is used to indicate what 
privileges the DPC allows that individual: 
0: registration 

The Document, Recipient, and Archive Retrieve records are keyed 
by documentNumber, The Organization records are keyed by biometricld. The 
EDD maintains secondary indexes on the Document senderld field, the 
Recipient recipientld field, and the Organization company name and title fields, 

1.5.24.4. Database Size 

The EDD's storage requirements depend primarily on the number of 
fax pages it will have to store since e-mail messages are relatively small 
compared to fax pages. Each fax page requires about 110 KB of storage. 
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Assuming 4 pages per fax, 2 faxes per person par day, and 30 million fax 
machines, the EDD requires 24 GB of storage to spool one day's worth of 
faxes. 

1,5.24.5. Security 

Documents are seat to and from the system encrypted using the 
BIA encryption mechanism. However, the encryption key is stored in the same 
database as the document. The document is left in its encrypted form to 
prevent casual disclosure, but individuals concerned about security of 
documents stored on the system should make some arrangement for additional 
encryption themselves, 

1.5.246. Message Bandwidth 

Each fax page requires about 1 10 KB which means that a Tl 
connection, with a throughput of 1 .54 MBits/second, can handle about 1.75 
fax pages per second, 

1.5.25. Electronic Signature Database 

1.5.25.1. Purpose 

The Electronic Signature Database (BSD) authenticates and tracks 
all electronic signatures created by the system. 

1 .5.25.2. Usage 

Individuals who are members of the system submit a 16-byte 
"message digest" for the document along with biomemc-PICs and obtain a 
"digital signature" which remains on file with the system in perpetuity. This 
digital signature encodes the individual's name, bsometric identification code, 
the authorized signature record number, document title, along with the 
timestamp at which the document was signed. 
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To verify a signature, a message digest for the document are first 
calculated (using RSA's MD5 for instance) and seat along with the document's 
signature tags. The ESD looks up the signature tags and validates the just 
recently calculated message digest against the message digest stored in the 
database. 

1.5.25.3. Database Schema 

The schema for the Electronic Signature record is: 
Electronic Signature: 

siguatureNmnber s intS 
signer - int4 
documentName s text 
checksum « intI6 
date ~ time 

The signer is the biometric identification code for the individual 
signing the document. The electronic signature record is hashed by 



LS.25.4. Database Size 

For each 1 GB of secondary storage, the Electronic Signature 
Database stores 27 million records (each record is about 32 bytes). 

1.5JE5.5. Dependencies 

The ESD has dependencies on the signer's biometric Identification. 
Since these signatures remain valid essentially forever, ESD records are not 
removed when the system deletes the signer's Individual Biometric Database 
record. Note that this requires the IBD to never reuse a biometric 
Identification. 
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1.5.26. Remote Merchant Database 

1.5,26.1. Purpose 

The Remote Merchant Database (RMD) stores information on 
merchants that provide goods or services over telephones, cable television 
networks, or the Internet. Each order sent by an individual using a 
properly-equipped terminal is routed through the merchant's order terminal to 
the system. 

LS.26.2. Usage 

Once an individual's remote transaction authorization is received 
and the MAC validated by the DPC, the merchant code is compared against 
the merchant code in the RMD. The merchant code, be it phone number, 
merchant-product credential, or internet address, exists in the RMD record 
under the correct merchant identification code or the DPC tenninates the 
request and returns an invalid merchant code error to the sending BIA terminal 
device. 

1.5.263. Database Schema 

The schema for the Remote Merchant record is: 
Remote Merchant; 

merchantld = int4 
merchantCode » chari6 
merchantType s intl 
puMcKey-inti6 

The Remote Merchant merchantType is one of: 
0: telephone 
1: CATV 
2: Internet 

The merchantld and merchantCode are both primary keys. No two 
RMD records have the same merchantld and merchantCode combination. 
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1.5.26.4, Database Size 

Assuming about 100,000 remote merchants, the RMD requires 
5 about 24 bytes per record for a total of about 2.4 MB storage required, 

1.5.26.5. Dependencies 

The RMD does not have any direct dependencies on any other DPC 
*G components. 

1.5.2?, System Performance 

The key performance number is how many financial authorization 
transactions the DPC handles per second. 

laGM: 

i . MACM checks the MAC (local) 
20 2, SNM checks the sequence number (network message) 

3. MDM decrypts the bioraetric-PIC block (local) 

4. Find IBD machine (local) 

5. Send identify request to the IBD machine (network message) 
25 la IBD machine: 

6. Retrieve all IBD records for the PIC (x seeks and x reads, where x is the 
number of pages required to store the biometric records). 

7. For each record, compare against its primary biometric (y/2ms where 
30 y is the number of records retrieved). 

8. If no reasonable match, repeat step 9 but compare against the secondary 
biometric (z * y / 2 ms, where y is the number of records retrieved and 2 is 
the probability no match is found). 

9. Update the best matching IBD record's checksum, queue and check for 
35 possible replay attacks (1 seek, 1 read, and 1 write). 
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10, Return the best matching IBD record or an error if fee match is not 
close enough (network message), 

laGM: 

5 

1 1, Authorize request with m external processor (network message) 

12, GM encrypts and MACs the response (local). 

13, Sends response packet back (network message). 

10 Total Disk Costs: 

x*(s + r) + y/2*(l +z) + s + r + w + 5 *n 

* (x + 1) * (s + r) + y / 2 * (I + z) + w + 5 * a 

[assume x is 20, y is 30, z is 5%; s ■* 1 0ms, r » 0ms, w « 0ms, n *» Qms] 
-2! * 10 ms+ 15* 1.05ms 
15 « 226 ms 

* 4.4 TPS 

[assiimex is 10, y is 15, zis 5%; s « 10ms, r ~0»s, w = 0ms, n « 0ms] 
= 11 * JOms+7.5 * 1.05ms 
= 118 ms 

20 = 8,4 TPS 

[assume x is 1, y is I , z is 5%; s « 10ms, r » 0ms, w « 0ms, n * 0ms} 
"2* 10 ms+ 1/2* 1.05 ms 
= 21 ms 
~ 47 TPS 

25 

The backup IBD machine also processes requests doubling effective TPS. 



Worst case (with 2 machines in use): 
Individuals per PIC TPS 
30 30 8 

15 16 
I 94 
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Average case (with 20 machines in use): 



Individuals per PIC TPS 

30 88 

15 m 

5 I 940 

Best case (with 40 machines in use): 

Individuals per PIC TPS 

30 ne 

10 15 336 

1 1880 



The ab ove is just an example of one configuration of the system as it could 
be implemented in a commercially viable manner. However, it is 
anticipated that this invention can be configured in many other ways which 
could incorporate the use of fester computers, more computers and other 
such changes. 

1.6. Terminal Protocol Flowchart 

The following set of protocol flows describe interactions between 
specific terminals, the DPC, the attached BIA, and other parties such as the 
credit/debit processor, and so on. 

1.6.1. Retail Point of Sale Terminal 

In this case, an RPT communicates with a retail BIA and the DPC 
to authorize a transaction. The transaction amount is 452,33, the individual's 
account is 4024-2256-5521-1212 merchant code is 123456, and the 
individual's private code is "I am My persuaded of it. " 

RPT BIA Set Language <Eagiish> 
BIA ~* RPT Ofc 

RPT ~» BIA Get Biometric <20> 
BIA/LCD: <Please place finger on lighted paael> 
Individual places fiager on scanner 



145 



WO 96/36934 



PCT/US96/07185 



BIA -* RPT Ok 

RPT ~> BIA Get Pin <40> 

BIA/LCD: <Pkase enter your PIC, then press <ester» 

fadividual esters PIC, then <emer> 
BIA -» RPT Ok 

RPT ~» BIA Get Account Number <4Q> 

BIA/LCD: <Now eocer your account index code, teen press <enter» 

Individual enters code, then <enter> 
BIA RPT Ok 

RPT -* BLA. Validate Amount <452 J3> <40> 

BIA/LCD: <Amount 452.33 OK?> 

Individual enters OK 
BIA RPT Ok 

RPT ~> BIA Assign Register <!> <123456> 
BIA ~* RPT Ok 

RPT -* Form Message <transactton> 

BIA -4 RPT <Traasacttoa Request Messages* 

BIA -» RPT OK 

BIA/LCD: <fm talking to DPC Central 
RPT -* DPC transaction Request Message> 

DPC: validate biometric, retrieve account number -» 4024-2256- 5521-1212 
DPC -4 VISA Authorize 4024-2256-3521-1212 452.33 123456> 
VISA ~> DPC <ok 4024-2256-5521-1212 452,33 123456 autho-code> 

DPC: get private code 
DPC -*• RPT transaction Response Message^ 
RPT -* BIA Show Response transaction Response Message> <§> 

BIA/LCD: transaction ok: I am felly persuaded ofit> 
BIA RPT <Ok <autfao-code» 

RPT: prints receipt with autho-code on it 

1.6,2, Internet Point of Sale Terminal 

In this case, an IPT communicates with a standard BIA and the 
DPC to authorize a transaction. The transaction amount is 45233, the 
individual's account is 4024-2256-5521-1212, the internet merchant is located 
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at merchautcom, his merchant code k 123456, and the individual's private 
code is 1 am fully persuaded of it." 

IFF -* merc&mt com <send me merchant code if resources available 
mersbant.com -» IPX <ok 123456 raerciiatstcoi»-publi£j-key> 

WT generates session key, encrypted with js3erejbaat.eom-ptibEc~ key 
IPT -» metckant.com <sessios key> 

All subseQuent communications with merchant are encrypted with session key. 
merctent.com WT <price and product mformaiion> 

IPT/Screea: displays price and product ioforrnaaoa 

^dividual; selects hem "fruitcake, price 45 .33" 
IPX ~* B1A S et Language <EagIisfa> 
BIA ~» IPT Ok 

IPT ~» BIA Get Bioraetrie <20> 

BIA/LCD: <Please place finger on lighted paoel> 

Individual places finger on scanner 
BIA -> IPT Ok 
IPT -+ BIA Get Pin <40> 

BIA/LCD: <Pfcase enter your PIC, then press <eoter» 

Individual enters PIC, itoen <enter> 
BIA ~* IPT Ok 

IPT BIA Get Account Number <40> 

BIA/LCD: <Now eater your account index code, then press <enter» 

Individual eaters code, then <enter> 
BIA -4 IPT Ok 

IPT -» BLA Validate Amount <45.33> <40> 

BIA/LCD: <Amount 45.33 0K?> 

Individual enters OK 
BIA ~* IPT Ok 

IPT ~> BIA Assign Register <!> <I23456> 
BIA -» IPT Ok 

IPX ~* BIA Assign Register <2> <mf:rchant com> 
BIA -* IPT Ok 

IPT ~» BIA Assign Register <3> <&uitcake> 
BIA -» IPT Ok 

IPT ~* BIA Form Message <remote rxansacnon> 
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BIA -* IPT <Remote Transaction Request MessagO 
BIA ~* IPT OK 

BIA/LCD: <i'm talking to DPC Central* 
IPT -» mcrchant.com <Reraote Transaoion Request Message> 
5 msrcbajK.com ~+ secure~<x>misct to DPC using DPC public key 

merchaat.com -» DPC <Remote Transaction Request Message> 

DPC: validate biometnc. retrieve account number ~» 4024-2256- 5521-1212 

DPC; validate internet mercham.com with code 123456 
DPC -* VISA<authori2e 4024-2256-5521-1212 45.33 123456> 
10 VISA -+ DPC <ok 4024-2256-552 1-1212 45.33 123456 autho- code> 

DPC: get private code 
DPC ~» merchaot.com ^Transaction Response Messaged 

mcrcb2tnt.com stores autho code 
merchant.com -» IPT <Transsction Response Message> 
15 IPT ~* BIA Show Response ^Transaction Response Message <8> 

BIA/LCD; <Transaction ok: I am fully persuaded of h> 
BIA -» IPT <TraasactiQQ ok> 



1.6,3. Interact Teller Terminal 



In this case, an ITT communicates with s standard BIA, the DPC, 
and a bank's internet server to perform routine and nonroutine home banking 
operations. Note that the DPC isn't involved in actually validating any 
transactions, but is only responsible for creating a valid set of network 
25 credentials and securing the communications line to the bank. 

ITT -~» bank.com <send me bank code if resources available* 
bank.com ~* ITT <ok 1200> 
ITT— > BIA Set Language <£nglish> 
30 BIA ~> ITT Ok 

ITT -» BIA Get Btometric <20> 

BIA/LCD: <Pleasa place finger on lighted panel> 

ladividual places finger on scanner 

bia -* rrr ot 

35 ITT -» BIA Get Pin <40> 

BIA/LCD: <Piease enter your PIC, then press <eater» 
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Individual enters PIC, then <eater> 
BIA -* FIT Ok 

RPT -* BIA Get Account Number <40> 
BIA/LCD: <Now eater your account index code, then press <eater» 
5 Individual eaters code, then <enter> 

BIA ITT Ok 

ITT~» BIA Assign Register <1> <1200> {bank code) 
ITT ~» BIA Assign Register <2> <baak.com> 

10 aiA~»rrrok 

HT -» BIA Assign Register <3> <3XT.porL bank.com.port> (TCP/IP addresses) 
BIA -* ITT Ok 

ITT ™» Form Message <net credential 
BIA ITT <network credential Request> 
15 BIA ~» ITT Ok 

BIA/LCD: <Fm talking to DPC CeatraJ> 
ITT DPC <network credential Request> 

DPC: validate biometrie, create cwdeatiaJ(time t acct, bank) 

DPC; get private code 

29 DPC ~* ITT <necwork credential Response> 

ITT -> BIA Show Response <network credential Respoase> 
BIA decrypt response, check response 
BIA/LCD: <CredaaiaI ok; I am fMy persuaded of it> 
BIA encrypt eredentiaL session key, challenge key with batik's public key 
25 BIA ITT <Secure Cotwection Request Message> 

BIA -* ITT <Session Key> 

BIA ~» ITT Ok 
BIA'ICD: <Seeure connection to bankeom in progress> 

ITT ~-» baak.com <Secure Connection Request Message> 

30 bank.eom decrypt with private key, validate credential, use shared key 
bank.com -* ITT <ok> 

Further transactions over the ITT ~» bank.com connections are ail 
encrypted by the ITT using the ITT/bank session key, 
35 Any transactions that the bank determines are non-routine must be 

validated by the individual using the BLVs challenge-response mechanism. 
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The challenge-response mechanism is available only while the BIA remains in 
the "secure connection" state. 

faauk,com -» ITT <validate Validation request» 
5 ITT -» BIA Validate Private <encrypted validation request> 

BIA decrypts chaHesge section, and displays it 

BIA/LCD: <Please OK: tiaasfer of 12,420.00 to 1023-3302- 2101-1 100> 
iwiivickal enters Ok 

BIA re-encrypts response using challenge key 
10 BIA/LCD: <Secure connection to bank.com in progress> 

BIA -» ITT <Ok <cncrypted validation response» 
riT -» baak.com <encrypted validation respoase> 

1.6.4. Electronic Signature Terminal 

15 

In this case, an EST communicates with a standard BIA and the 
DPC to construct digital signatures. The mdividuai's private code is "I am My 
persuaded of it" and the document to be signed is called "The Letter of 
Marque," 

20 

CET ~» BIA Set Language <Eaglish> 
BIA -» CET Ok 

CET ~* BIA Get Biometric <20> 

BIA/LCD : <Piease place finger on lighted pauel> 
25 Individual places finger on scanner 

BIA ~* CET Ok 
CET -» BIA Get Pin <40> 

BIA/LCD: <Please enter your PIC, tksa press <eater» 

Individual enters PIC, then <ester> 
30 BIA -» CET Ok 

CET ~> BIA Validate Document <Letter of Marque> <40> 

BIA/LCD: <Doc«ment "Letter of Marque" OK?> 

Individual enters OK 
BIA ~* CET Ok 

35 CET -* BIA Assign Register < i > <docnmeat MD5 vaiue> 

BIA -> CET Ok 
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CET ~> Form Message signature subnut> 
BIA -~> CET Electronic Signature Raquest> 
MA-*- CET OK 

BIA/LCD: <Tm talking to DPC Central 
CET -» DPC <Electroatc Signature Reqaest> 

DPC: validate biometric, create signature, return sig text code 

DPC: get private code 
DPC ~> CET <Eicctronic Signature Response> 
CET -* BIA Show Response <Electronic Signature Response> <&> 

BIA/LCD: <Docurnent ok: I am fully persuaded of it> 
BIA — CET <0k <s!g text code» 

L6,5. Certified Email Terminal 

In this case, a CET communicates with a standard BIA and the 
DPC to transmit certified electronic mail. The individual's private code is "I 
am fully persuaded of it", and the document name is "Post Captain." 

CET —i> BIA Set Language <Engiish> 
BIA ~~> CET Ok 

CET ~* BIA Get Biometric <20> 

BIA/LCD: <Piease place finger on lighted panei> 

Individuai places finger on scanner 
BIA -» CET Ok 
CET ~> BIA Get Pm <40> 

BIA/LCD: <Please enter your PIC, then press <cnter» 

Individuai enters PIC, thai <eoter> 
BIA ~» CET Ok 

CET — ► BIA Validate Document <Post Captain> <40> 

BIA/LCD: <Document "Post Captain" OK?> 

Individuai eaters OK 

CET/Screen: <Recipient hst? > 

Individuai caters <fredi@telerate.com joe;.ajreuter$.com> 
CET -* BIA Assign Register < \> <fred(^terate.com joef^reuiers.corn> 
BLA. ~f CET Ok 

CET «* Form Message <document subiBit> 
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BIA —> CET <Eleoioaic Document Submit Request> 
SIA -* CET OK 

BIA/LCD: <I'm talking to DPC Central 
CET ~> DPC <£iectronic Document Submit Request> 
5 DPC: validate biometric, create message, return message #00 1 234 

DPC: get private code 
DPC -» CET <Elcctronic Document Submit Response> 
CET -4 BIA Show Response Electronic Document Submit Responses <%> 
BIA/LCD; < Document ok: I am fully persuaded of it> 

10 BIA -* CET ^Document ok <1234» 

CET -» DPC <Electromc Document Data Request, 1234, section I, incomplete 
DPC ~» CET <Etectroiuc Document Data Response, incomplete 
CET —> DPC ^Electronic Document Data Request 1234, section 2, ineompie£e> 
DPC -» CET Electronic Document Data Response, incompiete> 

*5 CET -» DPC <EIectronic Document Data Request, 1234, section 3, incomplete^ 

DPC -» CET <Hectronk Document Data Response, mcompleto 
CET -> DPC <Ebctrotuc Document Data Request, 1234, section 4, doce> 
DPC -* CET Electronic Document Data Response, track 1234. 1 1234.2> 
DPC -> fred@teierate.com <email 1234.1 message arrived> 

20 DPC ~» joe@reuters.com <emaii 1234.2 message arrived> 

raaiienSteleraxe, com DPC ^received notiScanon email for 1234.1=* 
DPC -* senderraicompany.com <email 1234.1 recipient notified> 
maiier@reuters.eom -* DPC deceived notificatjoEi email for 1234.2> 
DPC ~» senden@company.com <cmail 1234.2 recipient noctfied> 

25 

[At Fred's CET: Fred sees the "message arrived" electronic mail message, and 
decides to go pick up the message] 

CET -* BIA Set Language <Engiisb> 
30 BIA -» CET Ok 

CET -» BiA Get Biometric <20> 

BIA/LCD: <Piease place finger on lighted panei> 

individual piaccs finger on scanner 
BIA -* CET Ok 

35 CFr-*BIAGetPb<40> BIA/LCD: <Piease enter your PIC> 

kdividual enters PIC then <enfer> 
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BIA ~* CET Ok 

CET BIA Assign Register <l> <1234. 1> 
BIA -+ CET Ok 

CET Form Message document retrieve> 

BIA -~> CET <Electronic Document Retrieve RequesP* 

BIA ~» CET OK 

BIA/LCD: <l'm talking to DPC Central 
CET -» DPC <Electronic Document Retrieve RequesP- 

DPC: validate bioroetric, lookup 1234. 1 

DPC; get private code 
DPC -» CET Electronic Document Retrieve Re$fK>nse> 
CET ~» BIA Show Response <Eleetraaie Document Retrieve Response <8> 

BIA/LCD: <Document ok: I am fully persuaded of it> 
BIA ~» CET <Docutnent ok <message key» 

CET/Sereea: decrypt, then show document 

1.6.6. Secure Fax Terminal 

In this case, a SFT communicates with an BIAVcatv and the DPC to 
transmit secure faxes. 

SFT -* BIA Get Biomemc <20> 

BIA/LCD; <Please place filler on lighted paael> 

Individual places finger on scanner 
BIA -* SFT Ok 

BIA/LCD: <Please enter your PIC, then press <eater» 

kdividuai enters PIC, then <enter> 
SFT -» BIA SetPin<40> 

BIA/LCD: <Please ester your Title Index, then press <enter» 

Individual enters title index, then <eater> 
SFT -4 BIA Set Title Index Code <40> 
BIA -» SFT Ok 

SFT/Screeo: <Recipieat? (add * for est, # at end)> 

Individual eaiers <l 510 944-4300*525#) 

SFT/Screen: Recipient? (add * for ext. # at end)> 

Indtviduai enters <l 415-877~?7?0#> 
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SFT/Screea: <Reciptcut? {add * for ext, # at end)> 

Individual eaters <#> 
SFT -» BIA Assign Register <J> <1 5109446300*525 I415*777770> 
BIA SFT Ok 

SFT -» Form Message <dacmtism mhmt> 
BIA ~» SFT <Secwe Fax Submit Request> 
BIA SFT OK 

BIA/LCD: <fta talking ta DPC CeatKii> 
SFT ~» DPC <Secure Fax Submit Requeso 

DPC: validate biometrie, create message, return message #001234 

DPC: get private cade 
DPC -* SFT <Secure Fax Submit Response 
SFT -* BIA Show Response <Secune Fax Submit Resp0ose> <I0> 

BIA/LCD: <Docuttiest ok: 1 am fully persuaded of it> 
BIA -+ SFT ^Document ok <C0I234» 

SFT -» DPC <Secure Fax Data Request. 1234, section i, kcoinplete> 

DPC -» SFT <Secure Fax Data Response, incomplete 

SFT -* DPC <Secure Fax Data Request, 1234, section 2, incomplete^ 

DPC -* SFT <Secure Fax Data Response^ incotapiete> 

SFT -» DPC <Secure Fax Data Request, 1234, section 3, incomplete 

DPC -* SFT <Secare Fax Data Response, incomplete 

SFT -4 DPC <Sectire Fax Data Request. 1234, section 4, dose> 

DPC -* SFT <Secure Fax Data Response 

DPC ~> amect-fex 15109446300 

DPC -+ SFT63G0 <rax-cover "Sam Spade" from "Fred foaw" 1234. ! 4 pages waiong> 

DPC ~+ disconnect 

DPC -+ eoanect-fex 14158777770 

DPC ~* SFT7770 <fax-cover "John Jett" from "Fred Jones" 1234.2 4 pages waiting> 
DPC -* disconnect 

[At Sam's SFT: Sam sees document fax cover arrive from Fred, fflitiates remevai 
of dcxaiment from DPC using tracking code 1234 J J 

SFT ~# BIA Get Biometrie <20> 
BIA/LCD: <Please place finger on Egtoed panel> 
Individual (Sam) places finger on scanner 
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BIA SFT Ok 

SFT 8IA Get Pin<40> 

BIA/LCD: <Pteasc enter your PfC, then press <enter» 

Individual (Sam) enters PIC, then <enter> 
BIA -+ SFT Ok 

SFT BIA Assign Register <1> <123<U> 
BIA -* SFT Ok 

SFT -t Form Message <Aacuitiznt retrieve> 
BU -* SFT <Secure Fax Retrieve Reqitest> 
BIA SFT OK 

BIA/LCD: <I'm talking to DPC Cetaral> 
SFT DPC <Secure Fax Retrieve Request> 

DPC: validate biomerric, lookup 1234.1, verify faiomctnc-PIC = Sam Spade 

DPC; lookup private code in database 
DPC -» SFT <Secare Fax Retrieve Response> 
SFT -* BIA Show Response <Secure Fax Retrieve ResponsO <8> 
BIA ~» SFT <Document ok: I ara fully persuaded of it <rrtessage key» 

SFT/Screen: <Documeat ok: I am fully persuaded of it> 

SFT/Screen: print fox 

1.6.7. Biometric Registration Terminal 

In this case, a BRT communicates with a registration BIA and the 
DPC to register an individual with the system. 

BRT ~* BIA Set Language <Enghsb> 
BIA ~> BRT Ok 

BRT -* BIA Get Biometnc <20> <prirnary> 
BIA/LCD: <Please place PRIMARY finger on lighted panei> 
Individual places primary finger on scanner 

BIA -* BRT Ok 

BRT -* BIA Get Btometric <20> <secondary> 
BIA/LCD: <Please place SECONDARY finger on lighted paael> 
Individual places secondary linger on scanner 

BIA ~» BRT Ok 

BRT ~* BIA Get Pin <40> 
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BIA/LCD: <Piease eater your PIC, then press <enter» 

Individual enters 123456, then <enter> 
BIA ~» BRT Ok 
BUT BIA Get Message Key 
BIA ~+ BRT <Ok <message key» 
BIA -» <Regisir3aon Request MessagO 

BRT/Serecn: <Name: > 

Representative enters <Fred G. Shultz> 

BRT/Screeo: <Address: > 

Representative enters <I234 North Main> 

BRT/Screcn: <Ztpcode: > 

Representative enters <94042> 

BRT/Scificrt: <Private code: > 

Representative queries individual then enters <I am fuliy persuaded of it > 
BRT/Screea; < Asset account list: > 

tive enters <2, 1001-2001-1020-201 1> (credit card) 

«rs <3, 1 00 1- 1 002-0039-22 12> {checking account) 
BRT/Screcn: <Emergertcy account: > 

Representative enters <I, 1001-1 002-0039-22 12> (emergency, checking 
account) 

BRT Form Message <registratioa> 
BIA BRT <Registration Request Message 
BIA -4 BRT OK 
BIA/LCD: <I'm talking to DPC Cestrai> 

BRT appends message-key-eocrypted personal inibrmaaoa to request 
BRT -» DPC Registration Request Message* <encrypted personal taformation> 

DPC: verify PIC 123456 
DPC -» BRT <Registratton Response Mcssage> 
BRT —> BIA Show Response <Registradon Response Message> <8> 

BIA/LCD: fRegistrarion ck: I am fully persuaded of it 123456> 
BIA ~* BRT <Ok> 
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1*6.8. Customer Service Terminal 

in this case, a CST communicates with a standard BIA and the 
DPC to verify the identity and the credentials of m individual, 

5 

CST ~> BIA Set Language <Eagliiih> 
BIA CST Ok 

CST -* BIA Get Biometnc <20> 

BIA/LCD: <Pleasc place finger oa lifted paael> 
^ Individual places finger oa scanner 

BIA -> CST Ok 
CST BIA Get Pin <40> 

BIA/LCD: <Please enter your PIC, then press <eater» 

kdividuai enters PIC, then <eater> 
15 BIA ~» CST Ok 

CST -> BIA Get Message Key 
BIA -* CST <Ok <message key» 

CST ~> Form Message <Individuai identity Request> 
20 BIA -» CST <Individual Identity Request> 

BIA -* CST OK 

BIA/LCD : <I ! m talking to DPC Central 
CST -* DPC <individuai Identity Request> 
DPC: get private code, individual's priv 
25 DPC -* CST individual Identity Reply> 

CST -» BIA Show Response <U*dividua] Identity Rcpiy> <8> 

BIA/LCD: <fdemity ok: I am fully persuaded of it> 
BR CST <Ok <individuai-naoie priv» 
CST: check priv to see if sufficient for CST use 

30 

1.6.9. Issuer TermiaaJ 

In this case, an IT communicates with a standard BIA and the DPC 
to authorize and send a batch of account addition and deletion requests to die 
33 EPC. The individual's private code is "I am fully persuaded of it", and the 

bank code is i200. 
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IT BIA Set Language <EngUsn> 

BiA-»rrok 

IT -» BIA Get Bictmetnc <20> 

BIA/LCD: <l 'lease place fiager on Sighted panei> 

IMivkhiai places fiager on scanner 
BIA -* IT Ok 
IT-* BIA Get Pits <4G> 

BIA/LCD: <Pkase ester your PIC, then prsss < 

Individiial enters PIC, then <enter> 

FT BIA Assign Register <1> <1200> 

BiA-^rrok 

H -4 BIA Get Message Key 

BIA -» IT <message key> 
BIA IT Ok 

IT — » BIA Form Message <issuer request* 
BIA IT <issuer Batch Request> 
BIA ~» IT OK 

BIA/LCD: <I'ra talking to DPC Central 
IT ~» DPC <Issxier Batch Rfiquest> <message-key-ei)crypted issuer batch> 

DPC: validate biometrtc, validate bank code 1200 vs. BIA identification 

DPC: get private code 

DPC: decrypt message using message key, execute issuer batch 
DPC -* IT <Issuer Batch Reply> 
IT ••■■> BIA Show Response <Issuer Batch Reply> <8> 

BIA/LCD: <Batch ok: I am folly persuaded of it> 

BiA-^rr<ok> 

1.6.10. Automated Teller Machinery 

In this case, an ATM communicates with an integrated ATM BIA 
and the DPC to identify an individual and obtain his bank account number. 
The individual's account is 2100-0245-377S-1201, bank code is 2100, and the 
individual's private code is "i am fully persuaded of it." 
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ATM ~» BIA Get Btonetric <20> 

ATM/LCD: <Piease place finger oh hghted paael> 

Individual places filler oa scanner 
BIA ~* ATM Ok 

ATM/LCD* <Pkase cater your PIC, then press <en£er» 

fadtVKjtai enters 123456 oa ATM keyboard, to <enter> 
ATM -* BIA Set Pin <123456> 
BIA ~» ATM Ok 

ATM/LCD: <Now enter your account index code, then press <enter» 

Individual enters 2, fees <enter> 
ATM ~* BIA Set Account Index Code <2> 
BIA ATM Ok 

ATM -+ BIA Assign Register <I> <2100> 
BIA -* ATM Ok 

ATM ~& Form Message <account access> 

BIA ~» ATM <Account Access Bequest Message> 

BIA -> ATM OK 

ATM/LED: <Vm talking to DPC Centrai> 
ATM DPC <Account Access Request MessagO 

DPC: validate biometric, retrieve account number -+2I00- 0245-377S-12QI 

DPC; get private code 
DPC -f ATM <Account Access Response Message? 
ATM ™» BIA Decrypt Response <Account Access Response Message 
BIA -* ATM <2 100-0245-3778-120 1> <bo emcrgeacy> <I am Mly persuaded of it> 

ATM/LCD: <i am &Hy persuaded ofit> 

At this point, the ATM has the account number it needs to 
continue, so it then retrieves the kforraaiion associated with the account 
number, and commences interacting with the individual. 

1-6.11. Phone Point of sale Terminal 

In this case, a PPT conraunicates with an integrated phone BIA 
and the telephone merchant to download information and purchase items 
securely using the telephone. The individual's PIC is 1234, the account index 
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code is 1, the merchant's phone number is 1 800 542-223 1, merchant code 
123456, and the actual account number is 4024-2256-5521- 3212. 

Note that the telephone strips the area code (1-800) from the telephone 
5 number before handing it to the system. 

Individual dials phone I S00542223 1 
PPT -* connect merchant 1 800542223 1 
PPT -+ BIA Assign Register i <542223 1> 
10 Sales rep answers. Individual selects item "fruitcake", Sales rep downloads info, 

merchant PPT <123456 fruitcake 43.54> 
PPT -* BIA Get Biometric <20> 

Phone/LCD: <Please piace finger on lighted panei> 

individual places finger on scanner 
15 BIA -» PPT Ok 

Phone/LCD: <Please enter your PIC, &eo press #> 

individual eaters 1234 on keypad, theater* (enter) 
PPT -» BIA Set Pin <1234> 
BIA — > PPT Ok 

20 Phone/LCD: <Now enter your account index code> 

Individual enters I, then <Cnter> 
RPT -* BIA Set Account index code <i> 
BIA ~* PPT Ok 

RPT -* BIA Assign Register <2> < 123456> 
25 BIA -* PPT Ok 

Phone/LCD- <Prcss U if amount 45.54 is ok> 

Individual enters # (yes) 
PPT ~> BIA Set Amount <43.54> 
BIA -> PPT Ok 

30 PPT ~» Form Message <rentoie transaction> 

BIA -» PPT <Remote Transaction Requests 

BIA -+ PPT Ok 
Phone/LCD : <Tm talking to DPC Central 

PPT -> merchant <Pnoae Transaaion Request> 
35 merchant -* DPC secure-connect to DPC using DPC~public-key 

merchant ~4 DPC <Phone Transaction Request> 
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DPC: validate biometric, retrieve account number ™» 4024- 2256-5521-1212 

DPC: validate merchant 5422231 has code 123456 
DPC -+ VISA Authorize 4024-2256-5521-1212 43.54 123456> 
VISA -c DPC <ok 4024-2256-5521-12 12 43.54 123456 autho- code> 
5 DPC: get private code 

DPC -» merchant <Transactio0 Response Mcssage> 

merchant examines response code 
merchant -* PPT <Transaetion Response MessagO 
PPT -4 BIA Decrypt Message transaction Response Messago 
10 BIA -* PPT Ok <I am My persuaded of it> <a«thc~code>> 

Phone/LCD: <chane> Transaction ok: 1 am folly persuaded of it 

l.fi.12. Cable-TV Point of sale Terminal 

15 In this case, a CPT communicates with an integrated eable-tv BIA 

and the Cable television merchant to download irrfonaation and purchase items 
securely using the cable television broadband network, The individual's PIC is 
1234, the account index code is 1, the channel is 5, the merchant code 123456, 
and the actual account number is 4024-2256-5521- 1212. 

20 

Individual tarns the television to channel 5. 
merchaat -* CPT <fmiteake 43.54 1 2345S> {broadcast) 

lodividual hits "bay" on TV Remote 

CPT/TV: <Buyiag foriteake for $43.54> 
25 CPT -» BIA Get Biomettic <20> 

CPT/TV: <PIease place finger on lighted panel> 

Individual piaees finger on scanner 
BIA CPT Ok 

CPT/TV: <Please enter your PIC, then press <eater» 
30 Individual enters 1234 on keypad, then "buy" 

CPT -* BIA Set Pin < I234> 
BIA CPT Ok 

CPT/TV: <Now enter your account index code> 

ladiwduai eaters 1, then <enter> 
35 SRPT-* BIA Set Account index code <3> 

BIA -* CPT Ok 
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RPT ~» BIA Assign Register <I> <channel 5, 15:30:20 PST> 
BIA -** RPT Ok 

CPT -» BIA Assign Register <?> <123456> 
BIA ~» CPT Ok 

CPT/TV: <Press "buy" if amount 45.54 is ok> 

Individual eaters "buy" 
CP7 -+ BIA Set Amount <43-54> 
BIA -* CPT Ok 

CPT -» Form Message <CabieTV traasaction> 
BIA -» CPT <CableTV Transaction Request* 
BIA -* CPT Ok 

CPT/TV: <J'm talking to DPC Central 
CPT -* CTV Center <CableTV Transaction Request> 
CTV Center -» merchant <CableTV Transaction Request* 
merchant -+ DPC secure-comcct to DPC using DPC-pubUc-key 
merchant -* DPC <CahieTV Transaction Request* 

DPC: validate biometric, retrieve account number ~» 4024-2256- 5521-3212 

DPC: validate merchant channel 5. current snow has code 123456 
DPC VISA Authorize 4024-2256-5521-1212 43.54 123456> 
VISA -* DPC <ok 4024-2256-5521-1212 43.54 123456 autha- codo 

DPC: get private code, mailing address 
DPC -> merchant <Transactioii Response Messaged 

merchant examines response code, records maiiing address 
merchant — y CTV Center <Traasaction Response Message* 
CTV Center ~* CPT ^Transaction Response Message* 
CPT -» BIA Decrypt Message transaction Response Message* 
BIA CPT <Ok <I am fully persuaded of it> <autho~code» 

CPT/TV: <chime> Transaction ok: 1 am fully persuaded of it 

From the foregoing, j: will be appreciated how the objects and 
features of the invention are met. 

First, the invention provides a computer identification system that 
eliminates the need for a user to possess and present a physical object, such as 
a token, in order to initiate a system access request. 
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Second, the invention provides a computer identification system 
that is capable of verifying a users identity, as opposed to verifying possession 
of proprietary objects and information. 

Third, the invention verifies the user's identity based upon one or 
more unique characteristics physically personai to the user. 

Fourth, the invention provides an identification system that is 
practical, convenient, and easy use. 

Fifth, the invention provides a system of secured access to a 
computer system that is highly resistant to fraudulent access attempts by 
non-authorized users. 

Sixth, the invention provides a computer identification system that 
enables a user to notify authorities that a particular access request is being 
coerced by a third party without giving notice to the third party of the 
notification. 

Seventh, the invention provides an identification system that allows 
for identification of the sender and recipient of an electronic message and/or 
facsimile. 

Although the invention has been described with respect to a 
particular tokenless identification system and method for its use, it will be 
appreciated that various modifications of the apparatus and method are 
possible without departing from the invention, which is defined by the claims 
set forth below. 



163 



wo mmM 



PCT/US96/Q7185 



5. GLOSSARY 

ACCOUNT INDEX CODE; 

A digit or an alpha-numeric sequence that corresponds to a paracular 
financial asset account 

AID: 

Authorized Individual Database; contains the Est of individuals authorized 
to use personal and issuer BIA devices. 

AOD; 

Apparatus Owner Database: central repository containing the 
geographic and contact information on the owner of each BIA. 

ASCH: 

American Standard Code for Information Interchange 
ATM; 

Automated Teller Machinery; uses encoded biometric identity 
information to obtain access to a financial asset management 
system, including cash dispensing and account management. 

BIA: 

Biometric input apparatus; collects biometric identity 
information, encodes and encrypts it, and makes it available for 
authorizations. Comes in different hardware models and software 
versions. 

Biometrics 

A measurement taken by the system of some aspect of an 
individual's physical person. 

Biometric ED: 

An identifier used by the system to uniquely identify an individual's 
biometric record (HUD - Individual Record ED) 
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BIO-PIC GROUP: 

A collection of algoritfamicaliy dissimilar biometrie samples linked to the 
same personal identification code 

5 BET: 

Biometrie Registration Terminal; located at retail banking outlets, 
BRTs combine biometrie registration sitformation with an 
individuai-seiected PIN and selected personal information to register 
individuals with the system, 

m 

CBC: 

Cipher Block Chaining: an encryption mode for the DES. 
CCD: 

15 Charged-Coupied Device 

CET: 

Certified Email Terminal; uses BIA to identify sender, encrypts 
document, sends to system. System retains, notifies recipient 
20 of message arrival in-system. Recipient identifies sel£ and then 

document is transmitted to recipient. Notification to transmitter 
once document is sent. Document is verified sent, secured by 
BIA encryption. Transmitter may inquire as to delivery status. 
Both participants must be system members. 

25 

COMMANDS: 

A program or subroutine residing in the DPC that performs a specific task, 
activated by a request message sent from a BIA-equipped terminal. 

, 30 CONTRACT ACCEPT/REJECT: 

The process by which an individual enters their BIO-PIC and instructs the 
DPC to register said individual's contractual acceptance or rejection of the 
terms contained within a document which had been sent by electronic 
facsimile to that individual. 
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CPT: 

Cable-TV Pomt-of-Sale TenainaJ: combines an onscreen display 
simulcast digital signal informing TV-top cable box of product 
information with product video, and an BIA controller remote which 
performs the biometric-pin validation using the CATV communications 
network. Order/autho/mailmg-address/item-id forwarded to merchant. 
Results of authorization are displayed on the TV. 

CSX: 

Customer Service Terminals; provide system customer service 
personnel with varying degrees of access (based on access privilege) 
the ability to retrieve and modify information on individuals in 
order to help people with account problems. 

DATA SEALING STEP: 

The conversion of plain text to cipher text (known as "encryption") in 
combination with the encrypted checksuinming of a message that allows 
information to remain in plain text while at the same time providing a 
means for detecting any subsequent modification of the message. 

DES: 

Digital Encryption Standard: a standard for the cryptographic 
protection of digital data. See standard ANSI X3.92-1981 

OETERMINAHON: 

The status of the command processed during the execution step. 

DPC: 

A data processing center, namely, the place and the entity where the 
hardware, software, and personnel are located with the goal of 
supporting a muitigigabyte biometric identity database. A DPC 
processes electronic messages, most of which involve performing 
biometric identity checks as a precursor to performing some action, 
such as a financial transfer, or sending a fax, or sending 
electronic mail, etc. 



166 



WO 96/36934 



PCT/US96/07185 



BSP: 

Digital Signal Processor: a class of integrated circuits that specialize 
in the mathematical operations required fay the signal processing 
applications. 

BDKPT: 

Derived Unique Key Per Transaction: See standard ANSI/ABA 
X9.24-1992 

EBB: 

Electronic Document Database: central repository containing ail 
pending faxes and electronic messages awaiting pickup by 
individuals. 

EMERGENCY ACCOUNT INDEX: 

The alpha -numeric digit or sequence selected by an individual which, when 
accessed, will result in a transaction being labeled by the system as an 
emergency transaction, potentially causing the display of false screens 
and/or the notification of authorities that said individual has been coerced 
into performing a transmission or transaction. 

ESB: 

Electronic Signature Database: central repository containing all 
MD5 and electronic signatures of all documents signed by anybody, 
referenced by authorization number. 

EST: 

Electronic Signature Terminal; uses BIA to identify individual, 
computer calculates checksum on document, sends checksum to system, 
system validates, tkiestarops, saves checksum, and returns with 
sigcode. Uses Internet as transport, EST also verifies 
signatures given a sig code and an MD5 calculation. 

FAR (False Accept Rate): 

The statistical likelihood that one individuai's biometric will be incorrectly 
identified as the biometric of another individual. 
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FALSE SCREENS: 

Displays of information which has been intentionally pre- determined to be 
subtly inaccurate such that a coercing party will not illegally obtain 
accurate data about an individual's financial assets, ail the while remaining 
unaware of the alteration of the information. 

FBBI: 

Fiber Digital Device Interface: a networking device that utilises a 
fiber optic token ring. 

FS; 

Field Separator 
FW: 

Firewall Machine; the ktemet-iocal net router that regulates traffic 
into and out of the DPC, 

GM: 

Gateway Machine: the mam processing computers m the DPC; runs 
most of the software. 

IBB; 

Individual Biometric Database; central repository for biometric, 
financial asset, and other personal information. Queries against 
the biometric database are used to verify identity for transaction 
authorizations and transmissions. 

IB: 

Issuer Database: central repository containing the institutions 
that are allowed to add and delete financial asset account numbers 
with the system. 

JML: 

IBD Machine List: a software module in the DPC determines which IBD 
machines are responsible for which PIN codes. 
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INTERNET MERCHANT: 

A retail account selling services or good to consumers by means of the 
Internet electronic network 

JFT; 

Internet Point-of-Sale Terminal: hems and merchant code 
from the internet, BIA htometric-PIN for validation, sent to 
system using internet, autho/order/PO # forwarded to merchant. 
System response using internet as well, displaying results on screen. 

ISSUER: 

A financial account issuer for financial assets to be registered with the 

mc, 

ISSUER BATCH: 

A collection of "add" and "delete" instructions compiete with biometric 
IBs, financial asset accounts, and account index codes verified and 
submitted by an issuer to the DPC. 

IT: 

Issuer Terminals; provides a batch connection to the system for 
issuers to add and remove (their own) financial asset account 
numbers from specific individual's IBD records. 

ITT: 

Internet Teller Terminal; authorizes network terminal session using 
encrypted credential obtained from DPC using biometric ID. 

LCD: 

Liquid Crystal Display; a technology used for displaying text. 
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MAC: 

Message Authentication Cods: an encrypted checksum algorithm, the 
MAC provides assurance tint the contents of a message have not been 
altered subsequent to the MAC calculation. See standard ANSI X9.9-1986 

MACM: 

Message Authentication Code Module: a software module in the 
DPC that handles MAC validation and generation for inbound and 
outbound packets. 

MDM: 

Message Decrypt Module: a software module in the DPC that 
encrypts and decrypts packets from or destined to an BIA device. 

MFM; 

Message Processing Module: a software module in the DPC that 
performs the processing of request packets, 

NETWORK CBEDEN1XAL: 

Both the individual and the bank are identified by the DPC to create the 
network credential. The credential includes the individual's identification as 
well as the context of the connection (i.e., the TCP/IP source and 
destination ports), DPC creates a network credential using the individual's 
account id, the time of day, and the bank code. The DPC signs this 
credential using Public Key Encryption and the DPCs Private Key. 

PFD: 

Prior Fraud Database: central repository for USD records which 
have had prior fraud associated with them. Every new customer's 
biometrics are checked against all PFD records with the intent of 
reducing recidivism. 

PGL: 

PIN Group List: a software module in the DPC that is responsible 
for rr^taining the configurarion of the IBD machines. 
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PIN; 

Personal Identification Number, a method for protecting access to an 
individual's account through secret knowledge, formed from at least one 
number. 

PIC: 

Personal Identification Code; a PIN formed from either numbers, symbols, 
or alphabetic characters, 

POS: 

Pomt-Of~Sale; a place where goods are sold. 
PPT: 

Phone Point-of-Sale Terminal; combines phone number wtifa 
merchant price and product information to authorize a transaction over a 
BIA-equipped telephone. Order/awiijorizatiorumaiiing-address/PO 
forwarded to merchant. Resulting authorization is displayed on phone 
LCD, or "spoken*, along with the individual's private code. 

RAM: 

Random Access Memory 

RF; 

Radio Frequency; generally refers to radio frequency energy 
emitted during the normal operation of electrical devices. 

REGISTERS: 

Memory reserved for a specific purpose, data set aside on chips and stored 
operands to instructions 

REQUESTS: 

Etcctromc instructions from the BIAto DPC instructing the DPC to 
identify the individual and thereby process the individual's command in the 
event the identification is successful 
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RAID: 

Remote Merchant Database: contains all merchant identification codes for 
merchant telephone and Cable TV order shops; indexed by merchant ID, 
Contains per-merchant system encryption codes as well. 

KPT: 

Retail Point-of-SaJe Terminal; combines encoded biometric 
identity mformation with retail transaction information (possibly 
from an electronic cash register) and formulates authorization 
requests of the system using X,25 networks, modems, etc, 

SECURE TRANSMISSION: 

An electromc message or facsimile wherein at least one party has been 
identified by the DPC. 

SFT: 

Secured Fax Terminal; uses BIA to identify sender, sends fax either 
unsecured, sender-secured, secured, or secured-confidentiai. The 
latter two require recipients to identify themselves using 
hiometrk-PIN, Uses "titles" (specified using a title index digit) 
to label outbound faxes. Sender may raquire as to delivery status. 
Both participants must be system members. Either sender or 
recipient can request that the fax be archived, 

SNM: 

Sequence Number Module: a software module in the DPC that 
handles the DUKPT sequence number processing for inbound 
request packets. Sequence number processing protects against replay 
attacks. 

Terminal: 

A device that uses the BIA to collect biometric samples and form request 
messages that are subsequently sent to the DPC for authorization and 
execution. Tenninais almost always append ancillary information to 
request messages, identifying counterparties and the like. 



172 



WO 96/36934 



FCT/DS96W718S 



TITLE EST>EX CODE: 

Alpha-numeric sequence uniquely identifying an individual's authorized 
role or capacity within the context of his employment 

Token: 

An inanimate object conferring a capability. 

TRACKING CODE: 

An alpha-numeric sequence assigned to data stored in or transmitted by the 
DPC, such that said sequence may be used to recall the data or obtain a 
report on the status of the transmission of the data. 

TRANSACTION; 

Aft electronic financial exchange 

TRANSMISSION: 

An electronic message other than an electronic financial exchange 

VAB: 

Valid Apparatus Database: central repository in which each BIA 
(with associated unique encryption codes) is identified, along with 
the owner of the BIA, 
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claim: 

L A voluntary tokenless identification computer system for determining an individual's 
identity from an examination of at lea st one biometric sample and a personal 
identification code gathered during a bid step, and comparison with previously 
recorded biometric sample and personal identification code gathered during a 
registration step, said system comprising; 

a. at least one computer, 

b. first gathering and display means for voluntary input of at least one 
biometric sample, personal identification code, and private code from an 
individual during the registration step, wherein the private code is selected 
by the individual; 

c. second gathering and display means for voluntary input of at least one 
biometric sample and personal identification code, from an individual 
during a bid step; 

d. first interconnecting means for interconnecting said first and second 
gathering and display means to said computer for transmitting the gathered 
biometric sample, personal identification code, and private code from said 
first and second gathering means to said computer; 

e. means tor comparison of biometric sample and personal identification code 
gathered during the bid step with the biometric sample and personal 
identification code gathered during the registration step, for producing an 
evaluation; 

f. execution means within said computer for storage of data and processing 
and execution of commands for producing a determination; and 

g. means for output of said evaluation, determination, or private code from 
said computer. 

2. The apparatus of claim 1 wherein the computer comprises means for detecting and 
preventing electronic intrusion of the computer system. 

3. The apparatus of claim 1 wherein the computer is placed remote from the gathering 
and display means. 

4. The apparatus of claim 1, the first and second gathering and display means further 
comprising; 

a. at least one biometric input means for gathering biometric samples further 
comprising a hardware and software component; 

b. at least one terminal means that is functionally partially or fully integrated 
with the biometric input means for input of and appending additional data; 
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c. at least one data entry, means for input of a persona] identification code 
where in said means is integrated either with the Diametric input means or 
the terminal means; and 

d. second interconnecting means for interconnecting said biometric input 
means, data entry means and said terminal. 

5 . The apparatus of claim 4 wherein said terminal further comprises at least one display 
means for display of data. 

6. The apparatus of claim 4 wherein the biometric input means has a hardware 
identification code previously registered with the computer, which makes the biometric 
input means uniquely identifiable to the computer. 

7. The apparatus of claim 4 wherein the hardware component further comprises; 

a. at least one computing module for data processing; 

b. erasable and non-erasable memory modules for storage of data and 
software; 

c. biometric scanner device for input of biometrics data; 

d. data entry means for entering data; 

e. digital communication port; and 

f means for prevention of electronic eavesdropping. 
S . The apparatus of claim 7 wherein the computing modules are connected in a manner to 
prevent monitoring of communications between said computing modules. 

9. The apparatus of claim 7 wherein the hardware component further comprises display 
means for display of data. 

10. The apparatus of claim 7 wherein the hardware component further comprises RF 
shielding . 

11. The apparatus of claim 4 wherein the hardware component further comprises a 
wireless communications means. 

12. The apparatus of claim 7 wherein the biometric input means is secured from physical 
tampering. 

13. The apparatus of claim 12 further comprising means for detection of physical 
penetration of the biometric input means. 

14. The apparatus of claim 13 further comprising means for electronic self destruction 
whereby software and data stored within the memory module are erased. 

15. The apparatus of claim 13 further comprising means for physical self destruction 
whereby the computing modules and memory modules are destroyed. 

16. The apparatus of claim 4 wherein the hardware component further comprises means 
for reading magnetic strip cards. 
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17. The apparatus of claim 4 wherein the hardware component further comprises means 

for reading a smart card, 
IS. The apparatus of claim 4 wherein the software component resides in a computing 
module and further comprises; 
5 a. electronically erasable memory module wherein at least one command 

interface module, a first set of software and associated data specifically 
configured for the intended use of the biometric input device and data are 
stored; and 

b. non-erasable memory module wherein a second set of software and 
associated data are stored. 

19. The apparatus of claim 18 said software component further comprising means for 
encryption of data from plaintext to ciphertext. 

20. The apparatus of claim 18 said software component further comprising means to 
detect alteration of data further comprising; 

15 a. a secret key; and 

b. an irreversible one way transformation of the data that cannot be 
reproduced without the secret key. 

21. The apparatus of claim 1 8 wherein the first set of software and associated data further 
comprising: 

20 a. biometric encoding algorithm; and 

b. encryption code. 

22. The apparatus of claim 18 wherein the second set of software and associated data 
further comprising: 

a. an operating system; and 
25 b. at least one device driver. 

23. The apparatus of claim 4 wherein said terminal is any electronic device and which 
issues commands to and receives results from the biometric input means. 

24. The apparatus of claim 23 wherein said terminal is selected from the group of facsimile 
machines, telephones, television remote control, personal computers, credit/debit card 

30 processors, cash registers, automated teller machines, wireless personal computers. 

25. The apparatus of claim 4 wherein said second interconnecting means is means for 
wireless communications, 

26. The apparatus of claim 1 wherein said first interconnecting means is selected from the 
group X.25, ATM network, Telephone network, Internet network, cable television 

35 network, cellular telephone network. 
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27. The apparatus of claim 1 wherein the comparison means further comprises means for 
encryption and decryption of data. 

28. The apparatus of claim 1 wherein comparison means further comprises means for 
identifying the hiometric input device. 

5 29. The apparatus of claim 1 wherein the computer system further comprises; 

a. at least one independent computer network system; and 

b. third interconnecting means for interconnecting said computer system with 
said counter party computer system. 

30. The apparatus of claim 29 wherein the third interconnecting means comprises an X.25 
10 network. 

31 . The apparatus of claim 1 wherein the execution means comprises at least one database 
for storage and retrieval of data. 

32. The apparatus of claim 3 1 wherein the data base further comprises an individual 
biometric data base. 

*5 33 . The apparatus of claim 3 1 wherein the data base further comprises a prior fraud check 

data base. 

34. The apparatus of claim 3 1 wherein the data base further comprises an electronic 
document data base. 

35. The apparatus of claim 31 wherein the data base further comprises an electronic 
20 signature data base. 

36. The apparatus of claim 1 wherein said output means is selected from the group of an 
X.25 network, ATM network, Telephone network, internet network, cable television 
network. 

37. The apparatus of claim 1 wherein said private code is generated by the computer. 

25 38, A method for voluntary and tokenless identification of individuals, and authentication 

of the identification, said method comprising the steps of: 

a. registration step wherein at least one biometric sample, personal 

identification code, and private code from an individual is gathered and 
stored; 

„ 30 b. bid step wherein at least one biometric sample and personal identification 

code from an individual is gathered; 

c. comparison step wherein the biometric sample and personal identification 
code gathered during the bid step is compared with the biometric sample 
and personal identification code gathered and stored during the registration 

35 step, for producing either a successful or failed identification result; 
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d. execution step wherein a command is processed and executed to produce a 
determination; 

e. output step wherein said identification result or determination is 
externalized and displayed; and 

£ presentation step wherein on successful identification of the individual, the 
private code is presented to the individual being identified. 

39. The method of claim 38 wherein both the registration and bid steps further comprise a 
biometric samp le check step wherein the quality of the biometric sample is verified. 

40. The method of claim 38 wherein the registration step further comprises a personal 
identification code and biometric sample dupEcation check step wherein the biometrics 
and personal identification code gathered during the registration step is checked 
against all previously registered biometrics currently associated with the identical 
personal identification code, 

41. The method of claim 38 wherein the registration step further comprises an ancillary 
data input step wherein ancillary data is collected. 

42. The method of claim 41 wherein the ancillary data further comprises name and address 
of the indi vidual. 

43. The method of claim 4 1 wherein the ancillary data further comprises a title of an 
individual 

44. The method of claim 43 wherein the ancillary data input step further comprises a title 
index assignment step wherein each title of the individual is assigned a code. 

45. The method of claim 41 wherein the ancillary data further comprises a financial asset 
account number. 

46. The method of claim 45 wherein the ancillary data input step further comprises an 
account index assignment step wherein each financial asset account number is assigned 
an index code. 

4?, The method of claim 38 wherein the registration step further comprises a prior fraud 
check step wherein the biometric sample gathered during registration is compared to a 
subset of previously registered biometric samples. 

48. The method of claim 38 wherein the registration step further comprises an emergency 
mechanism setup step. 

49. The method of claim 48 further comprising an emergency account index assignment 
step wherein an account index is labeled as an emergency account where in the event 
the account is accessed appropriate authorities are notified of the emergency. 

50. The method of claim 49 further comprising a false screen display setup step wherein 
there is assignment of false screen data. 
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5 1 . The method of ciaim 49 wherein access to various financial asset accounts is {united. 

52. The method of ciaim 38 wherein the registration step farther comprises a modification 
step wherein any previously entered ancillary data can be modified or deleted. 

53. The method of claim 38 wherein both the registration and bid steps fiirther comprise a 
data sealing step to provide the ability to detect alteration of the data further 
comprising; 

a. a secret key; and 

b. an irreversible one way transformation of the data that cannot be 
reproduced without the secret key. 

54. The method of claim 38, wherein the registration and bid steps further comprise an 
encryption step to convert the data from plaintext to ciphertext. 

55. The method of claim 38 wherein the bid or registration steps further comprise a 
transmission step wherein the data is transmitted. 

56. The method of claim 38 wherein the bid or registration steps is fiirther provided with a 
unique transmission code having a unique hardware identification code and 
incrementing sequence number which increases by one for each transmission, 

57. The method of claim 3 8 wherein the registration step further comprises choosing a 
language for communication in a set language step, 

58. The method of claim 38 wherein the bid step further comprises choosing a title in a set 
title number step. 

59. The method of claim 38 wherein the bid step further comprises choosing an account 
number in a set account number step. 

60. The method of claim 38 wherein the bid step further comprises validating an amount in 
a validate amount step. 

61. The method of claim 38 wherein the bid step further comprises entering an amount in 
an enter amount step, 

62. The method of claim 38 wherein the bid step further comprises validating a document 
in a validate document step. 

63. The method of claim 38 wherein the bid step further comprises appending ancillary 
data in an assign register step. 

64. The method of claim 63 the ancillary data further comprising a counter party 
identification code. 

65. The method of claim 38 wherein the bid or registration step further comprise aborting 
or canceling said step in a reset step. 

66. The method of claim 38 wherein the bid step further comprises transmission of data in 
a transmission step. 
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67. The method of claim 38 wherein the bid step further comprises choosing a language 
for communication in a set language step, 

68. The method of claim 38 wherein the comparison step further comprises use of the 
unique transmission codes to detect repeat transmissions. 

69. The method of claim 38 wherein the comparison step further comprises a counter 
party identification step using the counter party identification and unique transmission 
codes, 

70. The method of claim 38 wherein the comparison step comprises matching the 
individual's persona! identification code and biometric gathered during the bid step, 
with the personal identification code and biometric gathered during the registration 
step for positive identification of the individual. 

71 . The method of claim 70 wherein if there is no match of the personal identification code 
and biometric gathered during the registration step and the personal identification code 
and biometric gathered during the bid step, there is no recognition of the individual. 

72. The method of claim 3S wherein the execution step further comprises a debit/credit 
transaction step. 

73. The method of claim 72 wherein the debit/credit transaction step further comprises an 
address collection step. 

74. The method of claim 38 wherein the execution step further comprises an archiving step 
and a tracking code assignment step for archival of data. 

75. The method of claim 74 wherein the data is sent through a message digest encoding 
algorithm step to produce an electronically signatured document. 

76. The method of claim 38 wherein the execution step further comprises the retrieval of 
archived data using said tracking code. 

77. The method of claim 38 wherein the execution step further comprises a modification 
step wherein the title index code, account numbers and account index codes are added, 
deleted or modified. 

78. The method of claim 38 wherein the execution step further comprises an account 
number retrieval step where the account index code is used to retrieve an account 
number. 

79. The method of ciaim 3S wherein the execution step further comprises an emergency 
activation step. 

80. The method of claim 79 wherein the emergency activation step further comprises 
recognition of the emergency code and identifying ihe entire transaction as an 
emergency and notification of authorities. 
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81 . The method of claim 79 wherein the execution step farther comprises a false display 
step wherein previously designated, faise accounts or faise limitations on accounts are 
accessible. 

82. The method of claim 38 wherein the output step farther comprises an identification 
result notification step. 

83. The method of claim 38 wherein the output step farther comprises a determination 
notification step. 

84. The method of claim 38 wherein the output step farther comprises an emergency code 
step wherein authorities are notified. 

85. The method of claim 38 wherein the output step further comprises display of false 
screens. 

86. The method of claim 38 wherein the presentation step further comprises encryption, 
externalization, and decryption of the private code. 

87. A method for rapid search of at least one first previously stored biomeoic sample from 
a first individual, using a personal identification code-basket that is capable of 
containing at least one algorithmicaiiy unique second biometric sample from at least 
one second individual and which is identified by said personal identification code- 
basket, comprising: 

a. a storage step farther comprising; 

i. selection of a personal identification code by said first individual; 

ii. entering a biometric sample from said first individual; 

ill. locating the personal identification code-basket identified by the 
personal identification code selected by said first individual; 

iv. comparison of the biometric sample taken from said first individual, 
with any previously stored biometric samples in said selected 
personal identification code-basket, to make sure that the biometric 
sample entered by said first individual is algorithmicaiiy unique from 
the previously stored at least one biomeEric sample provided by at 
least one second individual; and 

v. storage of the entered biometric sample from said first individual in 
the selected personal identification code-basket if said sample is 
algorithmicaiiy unique from the at least one previously stored 
biometric sample from said at least one second individual; and 

b. a bid step further comprising; 

i. entering said selected personal identification code by said first 
individual; and 
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ii. entering a biometric sample by said first individual; and 
c, a comparison step further comprising; 

i. finding the personal identification code-basket that is identified by 
said persanai identification code entered by said first individual; and 
5 ii. comparison of the entered biometric sample from said first 

individual with said at least one stored biometric sample from said 
at least one second individual in said entered personal identification 
code-basket for producing either a successful or failed identification 
result. 
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